Clientside coding underestimated of bijbaantje?

[BCC]

Modbreak:

Dit topic is afgesplitst vanuit [PHP] Best practices

Erkens schreef op dinsdag 14 augustus 2007 @ 12:34:
[...]

Waarin verschilt een template engine van een "formbuilder"? Daarnaast moet die formbuilder ook geschreven zijn, hoe doe je het daar dan? Moet dat niet leesbaar zijn

Dat doe je in dit geval in PHP en dat moet prima leesbaar zijn. Een Template engine is IMHO puur het invullen van variabelen in HTML. Natuurlijk kun je daar wat handige truuks bij doen (loops, equations, etc), maar volledige forms schrijven horen daar wat mij betreft niet bij.
Het toevoegen van bijvoorbeeld Ajax elementen aan je pagina valt daar IMHO ook onder. Je wil niet een bak javascript in je view hebben staan, maar je wil een php call die aan de hand van wat parameters fijne javascript output. Het kan wel, maar het is veel mooier om het te scheiden. Daarnaast wil je zelf helemaal geen javascript schrijven

Voorbeeldje van view in RoR (ja, daar is geen syntax highlighting voor op T.net):

PHP:

<h1><%= _('New purchase')</h1>

<%= error_messages_for :purchase %>
<div class="small_form_div"> 
<% form_for(:purchase, :url => purchases_path) do |f| %>
  <p>
    <b>Option</b><br />
    <%= f.collection_select :option, PurchaseOption.find(:all), :id, :name %>
  </p>
  
    <p class="buttonContainer">
      <%= submit_tag _('Create') %>
    </p>
<% end %>

</div>

In de template vul ik dus wel bijvoorbeeld de vertaling van purchases in, maar de constructie van het formulier laat ik over aan de formbuilder. Bijvoorbeeld PHP Cake gebruikt dit soort constructies.

offtopic:
over minder fouten/exploit mogelijkheden valt weinig te zeggen aangezien dat afhankelijk is van de situatie

[...]

Ben ik het niet met je eens. Op het moment dat je voor elke edit-view een form script in je template schrijft, neemt de kans op een foutje enorm toe ten opzichte van een formbuilder die je overal gebruikt. En als je een lek/bug vind, kun je in 1x je volledige applicatie patchen.

[ Voor 34% gewijzigd door crisp op 15-08-2007 00:01 ]

[Erkens]

BCC schreef op dinsdag 14 augustus 2007 @ 20:23:
Dat doe je in dit geval in PHP en dat moet prima leesbaar zijn. Een Template engine is IMHO puur het invullen van variabelen in HTML. Natuurlijk kun je daar wat handige truuks bij doen (loops, equations, etc), maar volledige forms schrijven horen daar wat mij betreft niet bij.

Wat is een form? Niet meer dan een brok HTML, wat dus prima in een template past.

Het toevoegen van bijvoorbeeld Ajax elementen aan je pagina valt daar IMHO ook onder. Je wil niet een bak javascript in je view hebben staan, maar je wil een php call die aan de hand van wat parameters fijne javascript output. Het kan wel, maar het is veel mooier om het te scheiden. Daarnaast wil je zelf helemaal geen javascript schrijven

Ik wil wel javascript schrijven, dat is mijn dagelijkse werk namelijk En ik wil zeker niet dat PHP mijn javascript schrijft
In het geval van AJAX heb je overigens een "bijzondere" situatie, ik behandel die javascript die daar gebruikt wordt niet anders dan ik de functionele PHP code behandel: scheiden van de view.

Voorbeeldje van view in RoR (ja, daar is geen syntax highlighting voor op T.net):

PHP:

<h1><%= _('New purchase')</h1>

<%= error_messages_for :purchase %>
<div class="small_form_div"> 
<% form_for(:purchase, :url => purchases_path) do |f| %>
  <p>
    <b>Option</b><br />
    <%= f.collection_select :option, PurchaseOption.find(:all), :id, :name %>
  </p>
  
    <p class="buttonContainer">
      <%= submit_tag _('Create') %>
    </p>
<% end %>

</div>

In de template vul ik dus wel bijvoorbeeld de vertaling van purchases in, maar de constructie van het formulier laat ik over aan de formbuilder.

Maar is dit nog bruikbaar voor een designer die alleen HTML en CSS kan? Je hebt zo weinig controle over de uiteindelijke output, nu ken ik RoR niet zo goed, maar ik zie dit dus niet echt als een voordeel. Tenzij je de enige developer bent, en dan nog heb ik mijn twijfels, je bent wellicht snel klaar, maar voor onderhoud ben je denk ik langer bezig.

Ben ik het niet met je eens. Op het moment dat je voor elke edit-view een form script in je template schrijft, neemt de kans op een foutje enorm toe ten opzichte van een formbuilder die je overal gebruikt. En als je een lek/bug vind, kun je in 1x je volledige applicatie patchen.

ehm, als je een template hebt voor een formulier/formulierelementen dan is er weinig verschil, behalve dan dat je meer controle hebt over de uitvoer.

[crisp]

BCC schreef op dinsdag 14 augustus 2007 @ 20:23:
[...]

Het toevoegen van bijvoorbeeld Ajax elementen aan je pagina valt daar IMHO ook onder. Je wil niet een bak javascript in je view hebben staan, maar je wil een php call die aan de hand van wat parameters fijne javascript output. Het kan wel, maar het is veel mooier om het te scheiden.

Maar clientside mag je markup wel vervuilt zijn met inline script? MVC houdt daar ineens op?
Scripting is een functional layer bovenop je markup en zou dus unobtrusive en gescheiden van de markup toegepast moeten worden.

Daarnaast wil je zelf helemaal geen javascript schrijven

Inderdaad, dat moet je overlaten aan de programmeurs wiens expertise dat is

[BCC]

Erkens schreef op dinsdag 14 augustus 2007 @ 22:51:
[...]
Wat is een form? Niet meer dan een brok HTML, wat dus prima in een template past.

Volgens mij wil je vorm en functie altijd gescheiden houden in je applicatie. Een form is een functioneel onderdeel, HTML de vorm.

[...]

Ik wil wel javascript schrijven, dat is mijn dagelijkse werk namelijk En ik wil zeker niet dat PHP mijn javascript schrijft
In het geval van AJAX heb je overigens een "bijzondere" situatie, ik behandel die javascript die daar gebruikt wordt niet anders dan ik de functionele PHP code behandel: scheiden van de view.

Sorry dat ik je baan nu om zeep heb geholpen . Het genereren van Javascript voor o.a. AJAX is niets nieuws, het wordt zwaar toegepast in .NET, Java en Ruby On Rails, maar die mensen kunnen het natuurlijk mis hebben. Maar het idee van programmeren is natuurlijk wel om zoveel mogelijk te automatiseren

Maar is dit nog bruikbaar voor een designer die alleen HTML en CSS kan? Je hebt zo weinig controle over de uiteindelijke output,
nu ken ik RoR niet zo goed, maar ik zie dit dus niet echt als een voordeel. Tenzij je de enige developer bent, en dan nog heb ik mijn twijfels, je bent wellicht snel klaar, maar voor onderhoud ben je denk ik langer bezig.

Voor onderhoud is dit ideaal, omdat alle functie op 1 plek ligt (zoals ik net al noemde). Op dit moment werken we met 4 man met veel plezier aan deze codebase. Form is nog steeds perfect scheidbaar. Met CSS zijn ALLE elementen van de form prima te stylen. Ik gebruik op dit moment eigenlijk dezelfde code in de volledige applicatie (zeker 150 forms).

ehm, als je een template hebt voor een formulier/formulierelementen dan is er weinig verschil, behalve dan dat je meer controle hebt over de uitvoer.

Dit begrijp ik niet? Wat zie jij als uitvoer, de gegenereerde HTML?

[ Voor 4% gewijzigd door BCC op 14-08-2007 23:13 ]

[BCC]

crisp schreef op dinsdag 14 augustus 2007 @ 23:03:
Maar clientside mag je markup wel vervuilt zijn met inline script? MVC houdt daar ineens op?
Scripting is een functional layer bovenop je markup en zou dus unobtrusive en gescheiden van de markup toegepast moeten worden.

De scheiding gaat nog steeds op. Wie zegt dat ik de gegenereerde AJAX op de plek neergooi waar ik het aanroep?

Inderdaad, dat moet je overlaten aan de programmeurs wiens expertise dat is

offtopic:
Sorry, maar programmeurs die alleen javascript als expertise hebben, neem ik niet serieus . Helaas ben ik door recente projecten ook redelijk op de hoogte qua javascript .

[ Voor 6% gewijzigd door BCC op 14-08-2007 23:16 ]

[Erkens]

BCC schreef op dinsdag 14 augustus 2007 @ 23:07:
Volgens mij wil je vorm en functie altijd gescheiden houden in je applicatie. Een form is een functioneel onderdeel, HTML de vorm.

Een formulier is absoluut niet functioneel, het zijn niets meer dan een paar invoer velden welke na actie van de gebruiker uitgelezen worden.

Dit begrijp ik niet? Wat zie jij als uitvoer, de gegenereerde HTML?

yup

Sorry dat ik je baan nu om zeep heb geholpen . Het genereren van Javascript voor o.a. AJAX is niets nieuws, het wordt zwaar toegepast in .NET, Java en Ruby On Rails, maar die mensen kunnen het natuurlijk mis hebben.

Ik snap het al:

BCC schreef op dinsdag 14 augustus 2007 @ 23:09:
Sorry, maar programmeurs die alleen javascript als expertise hebben, neem ik niet serieus . Helaas ben ik door recente projecten ook redelijk op de hoogte qua javascript.

Blijkbaar ben je toch niet echt op de hoogte van wat javascript nu wel en niet is. Het gaat echt wel verder dan enkel wat standaard "ajax" componenten gebruiken die toevallig binnen je gebruikte framework beschikbaar zijn (hoe denk je overigens dat dat framework tot stand is gekomen?)

[BCC]

Erkens schreef op dinsdag 14 augustus 2007 @ 23:15:
Een formulier is absoluut niet functioneel, het zijn niets meer dan een paar invoer velden welke na actie van de gebruiker uitgelezen worden.

Dat ligt er aan hoe je het ziet. Op het moment dat bijvoorbeeld XForms mainstream worden, heb ik met 1 patch mijn volledige applicatie gefixt. Maar ik geef inderdaad toe dat het in principe HTML tags zijn.

Blijkbaar ben je toch niet echt op de hoogte van wat javascript nu wel en niet is. Het gaat echt wel verder dan enkel wat standaard "ajax" componenten gebruiken die toevallig binnen je gebruikte framework beschikbaar zijn (hoe denk je overigens dat dat framework tot stand is gekomen?)

Hoeveel patches heb jij voor prototype geschreven ? Ik trek hier javascript erbij als form ondersteuning, omdat dat vaak voorkomt en aansluit bij de TS.

[ Voor 6% gewijzigd door BCC op 14-08-2007 23:20 ]

[crisp]

BCC schreef op dinsdag 14 augustus 2007 @ 23:09:
[...]

De scheiding gaat nog steeds op. Wie zegt dat ik de gegenereerde AJAX op de plek neergooi waar ik het aanroep?

Ik heb gezien wat dergelijke frameworks aan javascript genereren, it made me cry...

offtopic:
Sorry, maar programmeurs die alleen javascript als expertise hebben, neem ik niet serieus . Helaas ben ik door recente projecten ook redelijk op de hoogte qua javascript .

Front-end coding (en dat behelst meer dan enkel javascript, ook markup, styling en een behoorlijke dosis kennis mbt browsers en quirks) is toch echt een vak apart. Ik ben dan ook zeer benieuwd naar je argumenten waarom een clientside coder niet serieus genomen hoeft te worden...

[Erkens]

BCC schreef op dinsdag 14 augustus 2007 @ 23:17:
Hoeveel patches heb jij voor prototype geschreven ?

offtopic:
is dat relevant? ok, geen, maar dat komt meer omdat ik niet dat framework gebruik, we gebruiken namelijk een eigen framework

crisp schreef op dinsdag 14 augustus 2007 @ 23:20:
Front-end coding (en dat behelst meer dan enkel javascript, ook markup, styling en een behoorlijke dosis kennis mbt browsers en quirks) is toch echt een vak apart. Ik ben dan ook zeer benieuwd naar je argumenten waarom een clientside coder niet serieus genomen hoeft te worden...

precies, jammer dat veel mensen het nog steeds zien als iets wat "erbij" hoort en ze er wel even bij kunnen doen

[BCC]

crisp schreef op dinsdag 14 augustus 2007 @ 23:20:
Front-end coding (en dat behelst meer dan enkel javascript, ook markup, styling en een behoorlijke dosis kennis mbt browsers en quirks) is toch echt een vak apart. Ik ben dan ook zeer benieuwd naar je argumenten waarom een clientside coder niet serieus genomen hoeft te worden...

Dit wordt wel heel erg offtopic, maar goed: Ik ben van mening dat een goede programmeur in elke taal kan programmeren. Als je de theorie begrijpt, is de syntax niet boeiend meer. Natuurlijk kun je expert zijn in een taal en alle quirks weten, maar dat in hoeverre dat slim/verstandig/handig is, weet ik niet direct. Op het moment dat jij alleen javascript kan en alle browsers gaan native flash of silverlight oid ondersteunen, dan sta je nogal hard op straat.

Ten tweede bevint javascript zich in een rare positie, omdat het een echte ondersteuningstaal is, als je het vanuit de webapplicatie kant bekijkt (zo is het ook vroeger begonnen). Je schrijft een webapp in PHP, .Net, Ror of iets anders en je gebruikt javascript eigenlijk clientside om de gebreken van je browser op te lossen, zodat de gebruiker toch van alle mogelijkheden van je webapp gebruik kan maken. Javascript coding is iets wat elke serieuze webdeveloper er bij moet doen, om zijn experience naar de gebruiker over te krijgen.

Nou kan de rest van je team natuurlijk de backend ontwikkelen en jij de frontend, maar dat is volgens mij wederom niet goed voor je eigen positie.

Erkens schreef op dinsdag 14 augustus 2007 @ 23:24:
[...]
precies, jammer dat veel mensen het nog steeds zien als iets wat "erbij" hoort en ze er wel even bij kunnen doen

Ik weet ook wel dat javascript programmeren echt niet een triviale bezigheid is, maar het is zeker niet het meest ingewikkelde wat er bestaat. Ik zie het gewoon als onderdeel van mijn app, die zelfs voor een ZEER groot deel uit javascript bestaat dat tegen een Ror backend praat. Maar we gaan nou wel heel erg ver van PHP Best practices

[ Voor 15% gewijzigd door BCC op 14-08-2007 23:33 ]

[crisp]

BCC schreef op dinsdag 14 augustus 2007 @ 23:28:
[...]

Dit wordt wel heel erg offtopic, maar goed: Ik ben van mening dat een goede programmeur in elke taal kan programmeren. Als je de theorie begrijpt, is de syntax niet boeiend meer. Natuurlijk kun je expert zijn in een taal en alle quirks weten, maar dat in hoeverre dat slim/verstandig/handig is, weet ik niet direct. Op het moment dat jij alleen javascript kan en alle browsers gaan native flash of silverlight oid ondersteunen, dan sta je nogal hard op straat.

Ten eerste schets je een zeer onwaarschijnlijk scenario en ten tweede heb ik het over een expertise die niet alleen javascript omhelst maar ook diverse andere clientside technieken. Bedenk daarbij ook dat zaken als SEO en accessibility daar ook onder vallen.

Ik ben het met je eens dat een goede programmeur niet gebonden is aan een taal; ik acht mezelf ook behoorlijk capabel in diverse andere talen op andere platformen, alleen weet ik niet van alle platformen alle ins en outs itt het browserplatform (wat behoorlijk lastig is door de heterogene omgeving wat bij serverside platforms veel minder speelt).

Ten tweede bevind javascript zich in een rare positie, omdat het een echte ondersteuningstaal is, als je het vanuit de webapplicatie kant bekijkt. Je schrijft een webapp in PHP, .Net, Ror of iets anders en je gebruikt javascript eigenlijk clientside om de gebreken van je browser op te lossen, zodat de gebruiker toch van alle mogelijkheden van je webapp gebruik kan maken. Javascript coding is iets wat elke serieuze webdeveloper er bij moet doen, om zijn experience naar de gebruiker over te krijgen.

Binnen een webapplicatie dient scripting toch zeker een heel duidelijk doel. De stelling dat het is om gebreken van browsers op te lossen is er een die slaat als een tang op een varken. Scripting is de manier om een browser als applicatieplatform te kunnen gebruiken, en dat zal in de toekomst enkel nog sterker gaan spelen. Per slot van rekening is HTML primair een markup language en is het aantal usecases dat behavioral elements in de HTML specificatie rechtvaardigd maar beperkt. Daartegenover staan ontelbare zeer specifieke usecases waarvoor scripting dus de geëigende methode is.

Ik vraag me af wat jouw definitie is van een serieuze webdeveloper. Als je front-end development al niet serieus neemt en afdoet als iets wat je "erbij" moet doen dan denk ik dat je jezelf al niet een serieuze webdeveloper zou mogen noemen.

Nou kan de rest van je team natuurlijk de backend ontwikkelen en jij de frontend, maar dat is volgens mij wederom niet goed voor je eigen positie.

Ik doe zelf op dit moment beide.

Ik denk dat het juist heel goed is voor je positie om niet een belangrijk aspect van web(application) development te bagatelliseren. Kwaliteit moet zich uiten op alle fronten, en als je op een bepaald front de kennis mist dan is het echt geen schande om dat toe te geven en dat aan anderen over te laten.

[BCC]

Eh, leuk dat dit is afgeplists, maar je hebt nu ALLE comments van mij uit de andere thread verwijdert. Dat lijkt me niet helemaal de bedoeling. Mag het form voorbeeld iig terug?

[ Voor 10% gewijzigd door BCC op 15-08-2007 08:22 ]

[BCC]

crisp schreef op dinsdag 14 augustus 2007 @ 23:46:
[...]
Ten eerste schets je een zeer onwaarschijnlijk scenario en ten tweede heb ik het over een expertise die niet alleen javascript omhelst maar ook diverse andere clientside technieken. Bedenk daarbij ook dat zaken als SEO en accessibility daar ook onder vallen.

Logischerwijs.

Binnen een webapplicatie dient scripting toch zeker een heel duidelijk doel. De stelling dat het is om gebreken van browsers op te lossen is er een die slaat als een tang op een varken. Scripting is de manier om een browser als applicatieplatform te kunnen gebruiken, en dat zal in de toekomst enkel nog sterker gaan spelen.

Ik ben met je eens dat het op dit moment de manier is om de browser als app platform te laten functioneren. In de toekomst denk ik echter dat dit gaat veranderen.

Per slot van rekening is HTML primair een markup language en is het aantal usecases dat behavioral elements in de HTML specificatie rechtvaardigd maar beperkt. Daartegenover staan ontelbare zeer specifieke usecases waarvoor scripting dus de geëigende methode is.

Op dit moment

Ik vraag me af wat jouw definitie is van een serieuze webdeveloper. Als je front-end development al niet serieus neemt en afdoet als iets wat je "erbij" moet doen dan denk ik dat je jezelf al niet een serieuze webdeveloper zou mogen noemen.

Erbij is misschien het verkeerde woord. Ik denk dat je je nooit puur op de front of de backend kan focussen.

Ik denk dat het juist heel goed is voor je positie om niet een belangrijk aspect van web(application) development te bagatelliseren. Kwaliteit moet zich uiten op alle fronten, en als je op een bepaald front de kennis mist dan is het echt geen schande om dat toe te geven en dat aan anderen over te laten.

Zoals altijd bij de IT moet je enorm opassen om expert ergens in te worden. Op het moment dat die techiek verdwijnt ben je hard het bokje.

Omdat je de titel van deze tread breder hebt getrokken van javascript naar ClientSide conding gaat dat argument wat dat betreft natuurlijk niet op, maar dat was niet de initiele insteek van deze tread.

[ Voor 4% gewijzigd door BCC op 15-08-2007 08:26 ]

[BikkelZ]

Ik heb echt een hekel aan front-end gedoe, of het moet echt specifiek gaan om iets wat in JavaScript gebouwd moet worden om de applicatie te vormen. Vormgeven en CSS gepiel daar bestaan echt andere mensen voor, mensen die dat leuk vinden.

[Janoz]

crisp schreef op dinsdag 14 augustus 2007 @ 23:46:
Ten eerste schets je een zeer onwaarschijnlijk scenario en ten tweede heb ik het over een expertise die niet alleen javascript omhelst maar ook diverse andere clientside technieken. Bedenk daarbij ook dat zaken als SEO en accessibility daar ook onder vallen.

Zodra je over echte webapplicaties begint is SEO ineens helemaal niet zo heel belangrijk meer. Ik wil helemaal niet dat google mijn webmail(applicatie) indexeert.

Als je echt over webapplicaties praat wil ik niet eens meer met javascript werken en voor elk mogelijke browser weer zelf die uitzondering maken. Ik zie daarom veel meer heil in dingen als GWT of Flex (of iets als JSF, maar daarover ben ik nu nog niet zo enthousiast). In dat geval hebben andere (grote) partijen dat hele clientside gedoe al voor je gefixed en kun je tegen een eenduidige 'interface' aan ontwikkelen.

[Niemand_Anders]

Als programmeur hoef je echt niet alle 100+ programmeertalen te kennen. Programmeren is meer dan alleen if-jes en while loopjes schrijven. Aan de andere kant moet een programmeur zich ook weer niet beperken tot 1 taal. Afgaand op de thread praten we hier dan voornamelijk over web development. Talen zoals c en c++ kunnen zeer goed gebruikt worden (bijvoorbeeld als apache module of ISAPI dll), maar dat is zeker niet de eenvoudigste keus (memory management, etc).

Web development zelf kan opgesplitst worden in twee zaken. Presentatie en business. Voor de presentatie laag heb je als programmeur / graphic artist enige kennis nodig van (x)html, css en javascript. Aan de business kant (server-sided) worden voornamelijk 3 platformen gebruikt: PHP, Java en .NET. PHP is een erg gemakkelijke taal, maar daar zit ook direct het nadeel. Alle variabele zijn loose typed, want betekend dat $var het ene moment 156 kan bevatten en twee seconden later een referentie naar een database of een stuk tekst. De meeste bugs die in een PHP web applicatie worden gevonden hebben meestal hierop betrekking. Platformen zoals java en .net (c#) zijn strong typed en daarmee kan al tijdens de compilatie worden achterhaal dat een statement als 'int a = "abc";' niet correct is.

De talen C# en java zijn bevatten veel overeenkomsten echter hun platformen (toolkits) zijn totaal verschillend. Maar juist in die toolkits zit juist de kracht van zo'n platform en als je die niet goed kent zal je web applicatie minder goed presteren. Ook heb je dan de kans dat je het wiel opnieuw uit vind.

Een taal leren is inderdaad niet zo lastig, want de syntax van de talen c(++), php, c#, java en perl bevatten erg veel overeenkomsten, dat maakt het wat eenvoudiger om te beginnen. In al deze talen werken reguliere expressies op een andere manier. Daarnaast heeft elk platform ook nog eens zijn eigen best practices en coding standaarden.

Wij (het bedrijf waar ik werk) geven meestal de voorkeur aan een gecompileerde taal. Waarom? Omdat een programmeur op een productie website dan niet 'even snel' een regel code kan toevoegen. Iets wat regelmatig gebeurde bij asp, php en perl websites met alle gevolgen van dien. Ook ik heb mij daar weleens schuldig aan gemaakt. Bij ons ligt momenteel de voorkeur bij .net. Dit heeft vooral te maken dat .net op meer plaatsen dan alleen web- en desktop development kan worden gebruikt. .net komt inmiddels ook terug in MS SQL 2005+, office en nu ook silverlight. Dat maakt dat een c# programmeur op verschillende soorten development kan worden gezet wat de efficientie van een programmeur ten goede komt.

Maar er zijn ook genoeg bedrijven welke zich beperken tot apache en php. Er bestaat (nog) geen ideale programmeer taal op platform. Elk bedrijf/programmeur zal daarin een keuze moeten maken. Die keuze wordt eenvoudig als je meerdere talen beheerst.

p.s. De quirks van een taal dat is nou juist meestal waarom een programmeur net voor die taal heeft gekozen want in elke taal kun je een hello world applicatie schrijven. Is een opdrachtgever geinteresseert in een hello world applicatie? Nee. Die heeft specifieke wensen en op basis daarvan wordt een taal/platform gekozen. Daarom kom je weinig in c++ geschreven websites tegen en ook weinig in php geschreven desktop applicaties. Elke taal heeft een primair domein waarvoor het geschreven is. Sun en Microsoft doen echter wel goed hun best om hun domein zo breed mogelijk te krijgen.

[Janoz]

BikkelZ schreef op woensdag 15 augustus 2007 @ 08:34:
Ik heb echt een hekel aan front-end gedoe, of het moet echt specifiek gaan om iets wat in JavaScript gebouwd moet worden om de applicatie te vormen. Vormgeven en CSS gepiel daar bestaan echt andere mensen voor, mensen die dat leuk vinden.

Ik heb tot nu toe enkele keren met vormgevers samen gewerkt, en als je duidelijk van elkaar weet wie wat doet is het heel goed te doen. Ik zorgde gewoon dat ik zo semathisch juist mogelijk html opleverde en maakte duidelijk aan de vormgever dat mijn wil absoluut geen wet was. Als hij ergens een div bij wilde of een specifiek id aan een object dan deed ik dat. Ik denk dat vooral dat laatste erg belangrijk is.

Bij veel van mijn collega's zag ik toen dat de vormgevings afdeling zich conformeerde aan beperkingen die er eigenlijk helemaal niet waren, terwijl veel programmeurs die dingen deden omdat ze dachten dat het wel handig zou kunnen zijn voor de vormgevers.

[BikkelZ]

Janoz schreef op woensdag 15 augustus 2007 @ 09:02:
[...]


Ik heb tot nu toe enkele keren met vormgevers samen gewerkt, en als je duidelijk van elkaar weet wie wat doet is het heel goed te doen. Ik zorgde gewoon dat ik zo semathisch juist mogelijk html opleverde en maakte duidelijk aan de vormgever dat mijn wil absoluut geen wet was. Als hij ergens een div bij wilde of een specifiek id aan een object dan deed ik dat. Ik denk dat vooral dat laatste erg belangrijk is.

Bij veel van mijn collega's zag ik toen dat de vormgevings afdeling zich conformeerde aan beperkingen die er eigenlijk helemaal niet waren, terwijl veel programmeurs die dingen deden omdat ze dachten dat het wel handig zou kunnen zijn voor de vormgevers.

Het scheelt een boel als je allebei betrokken bent in de conceptfase, dan maakt het ook niet meer uit of ik eerst een bijna kale resultset aanlever of ik juist een platte HTML file aangeleverd krijg die ik moet gaan integreren, omdat je allebei precies weet wat het moet worden.

[OkkE]

Goede clientside coding is imho zeker geen bijbaantje, maar wordt wel vaak onderschat. Het is zeker niet makkelijk om goede unobstructive javascript code te schrijven, die browser onafhankelijk is.

Ook HTML/CSS wordt nog al eens onderschat, in mijn ogen. Er komt nog aardig wat bij kijken om alle bugs/hackes/problemen te kennen en op te lossen m.b.t. hoe browsers CSS behandelen. Om nog maar niet te beginnen over semantiek, waar hele discussies over (kunnen) ontstaan.

[thalyric]

indeed ... clientdise coding is ook een vak apart. Het is inderdaad niet alleen Javascript. Het is alles erom heen zoals CSS,crossbrowser maken, symantisch goed (dus goed html'en). Vooral crossbrowser is hedendaags wel irritant. Heb nu een vrij complex website in de maak die het doet in IE6,FF 2, IE7 en Safari. En dan heb ik nog geen hacks gebruikt (whooohooo).

[crisp]

Janoz schreef op woensdag 15 augustus 2007 @ 08:57:
[...]

Zodra je over echte webapplicaties begint is SEO ineens helemaal niet zo heel belangrijk meer. Ik wil helemaal niet dat google mijn webmail(applicatie) indexeert.

Als je echt over webapplicaties praat wil ik niet eens meer met javascript werken en voor elk mogelijke browser weer zelf die uitzondering maken. Ik zie daarom veel meer heil in dingen als GWT of Flex (of iets als JSF, maar daarover ben ik nu nog niet zo enthousiast). In dat geval hebben andere (grote) partijen dat hele clientside gedoe al voor je gefixed en kun je tegen een eenduidige 'interface' aan ontwikkelen.

Feit is dat er tussen webpagina's en webapplicaties een groot stuk overlap zit, namelijk de webpagina's met applicatie-functionaliteit zoals voorbeeld ons reactie- en moderatiesysteem.

Het probleem van front-end code generators is dat het je behoorlijk beperkt in je mogelijkheden en de gegenereerde code vaak sub-optimaal is. Dergelijke tools confirmeren zich ook te vaak naar de least dominor qua beoogd platform (webbrowsers).

BCC schreef op woensdag 15 augustus 2007 @ 08:25:
[...]

Ik ben met je eens dat het op dit moment de manier is om de browser als app platform te laten functioneren. In de toekomst denk ik echter dat dit gaat veranderen.

Ik verwacht dat browsers steeds consistenter en meer mature zullen gaan worden. Op dit moment zie je al dat die ontwikkelingen steeds sneller gaan. Een complete omslag naar andere technologieën en methodieken zie ik echter niet zo snel gebeuren.

[...]

Erbij is misschien het verkeerde woord. Ik denk dat je je nooit puur op de front of de backend kan focussen.

Ik denk dat beide vlakken even belangrijk zijn en dus evenveel de focus verdienen. Feit is dat elk vlak een geheel andere expertise vereist, en experts op beide vlakken zijn nagenoeg non-existent.

[...]

Zoals altijd bij de IT moet je enorm opassen om expert ergens in te worden. Op het moment dat die techiek verdwijnt ben je hard het bokje.

Daarmee spreek je jezelf tegen als je stelt dat een goede programmeur in elke taal kan programmeren (hetgeen ik onderschrijf, ik ben zelf begonnen in de IT als RPG/400 en COBOL programmeur ). Uiteraard dien je jezelf gewoon op de hoogte te houden van nieuwe ontwikkelingen en indien nodig jezelf gewoon nieuwe technologieën aan te leren. Expertise is sowieso nooit van de ene dag op de andere niets meer waard.

Omdat je de titel van deze tread breder hebt getrokken van javascript naar ClientSide conding gaat dat argument wat dat betreft natuurlijk niet op, maar dat was niet de initiele insteek van deze tread.

Bij veel mensen leeft nog steeds het idee dat javascript een 'simpel taaltje' is dat prima door een of andere serverside tool gegenereerd kan worden. Daarmee doe je ten eerste de taal zelf tekort en je beperkt jezelf onnodig. Een goede javascript programmeur kan dingen doen die jij nooit voor mogelijk had gehouden maar een serverside programmeur die javascript 'erbij' doet produceert in veel gevallen verschrikkelijke gedrochten met allerlei crossbrowser issues.

[JKVA]

thalyric schreef op woensdag 15 augustus 2007 @ 10:20:
indeed ... clientdise coding is ook een vak apart. Het is inderdaad niet alleen Javascript. Het is alles erom heen zoals CSS,crossbrowser maken, symantisch goed (dus goed html'en). Vooral crossbrowser is hedendaags wel irritant. Heb nu een vrij complex website in de maak die het doet in IE6,FF 2, IE7 en Safari. En dan heb ik nog geen hacks gebruikt (whooohooo).

Ik denk dat er tegenwoordig een omslag gemaakt wordt. Een tijdje geleden keken veel back end developers neer op front end ontwikkelaars. Die hadden het idee van: "die maken een paar schermpjes".

Met de nieuwe frameworks is daar een omslag in gekomen, omdat die back end developers er ineens achter kwamen dat front end development toch vrij moeilijk is. Je moet immers alle troep die uit het back end terugkomt verwerken tot iets moois, de weblaag wordt steeds dikker en complexer met meer navigatie en zo. Momenteel ben ik ongeveer de enige "JSF kenner" bij mijn werkgever en ik kan je zeggen, daar heb ik op alle vlakken baat bij.

Nu lijkt het nog een stap verder te gaan, door de massale populariteit van AJAX en RIA's. Wederom ben ik bij ons de meest ervaren Ajaxcied en de AJAX cursus die ik geef (net als JSF cursus) heeft continu een wachtlijst.

Ik zie tegenwoordig front end development zelfs als complexer dan back end development, omdat je veel meer flows in je code krijgt. Bij eend back end kun je zelf alle regels bepalen wat het gemakkelijker maakt dan bij front ends waar je vast zit aan enorm veel randvoorwaarden.

Niemand_Anders schreef op woensdag 15 augustus 2007 @ 08:59:
Als programmeur hoef je echt niet alle 100+ programmeertalen te kennen. Programmeren is meer dan alleen if-jes en while loopjes schrijven. Aan de andere kant moet een programmeur zich ook weer niet beperken tot 1 taal. Afgaand op de thread praten we hier dan voornamelijk over web development. Talen zoals c en c++ kunnen zeer goed gebruikt worden (bijvoorbeeld als apache module of ISAPI dll), maar dat is zeker niet de eenvoudigste keus (memory management, etc).
[...]

Je moet idd niet alle talen kennen. Aan de andere kant vind ik het ook niet goed als een Java programmeur niet weet wat een closure is. Java heeft misschien geen closures, maar een closure is een vrij algemeen concept en je moet dat als enigszins opgeleid en dikbetaalde professional gewoon kennen. Aan de andere kant lijkt het me ook vrij normaal dat een JavaScript developer een beetje van multithreading weet. Niet de details, maar wel een globaal beeld van wat er allemaal speelt.

[BikkelZ]

crisp schreef op woensdag 15 augustus 2007 @ 11:07:
[...]

Bij veel mensen leeft nog steeds het idee dat javascript een 'simpel taaltje' is dat prima door een of andere serverside tool gegenereerd kan worden. Daarmee doe je ten eerste de taal zelf tekort en je beperkt jezelf onnodig. Een goede javascript programmeur kan dingen doen die jij nooit voor mogelijk had gehouden maar een serverside programmeur die javascript 'erbij' doet produceert in veel gevallen verschrikkelijke gedrochten met allerlei crossbrowser issues.

Ik zeg niet dat iedere vooruitgang een verbetering is, maar het is wel zo dat JavaScript een stuk moderner is dan de meeste programmeurs zijn. JavaScript heeft vaak een behoorlijk frisse kijk op dingen. Bijna net alsof een stel geeks de opdracht gekregen hadden een simpel scripttaaltje te ontwikkelen en en passant nog even wat nieuwe dingen er stiekem in gepropt hebben die ze graag eens zouden willen uitproberen in een programmeertaal.

[BCC]

crisp schreef op woensdag 15 augustus 2007 @ 11:07:
Ik denk dat beide vlakken even belangrijk zijn en dus evenveel de focus verdienen. Feit is dat elk vlak een geheel andere expertise vereist, en experts op beide vlakken zijn nagenoeg non-existent.

True, maar volgens mij is het absoluut niet te scheiden. Iedereen doet zijn best om vorm en functie te scheiden, maar het is volgens mij absoluut onmogelijk: je kan best een heel slim formulier hebben, maar als de user door 48 schermpjes moet klikken om er te komen, dan een onhandig forumulier op pagina 1 best een betere oplossing zijn. Volgens mij moet je expert op beide vlakken zijn als je goede software wilt kunnen afleveren.

Bij veel mensen leeft nog steeds het idee dat javascript een 'simpel taaltje' is dat prima door een of andere serverside tool gegenereerd kan worden. Daarmee doe je ten eerste de taal zelf tekort en je beperkt jezelf onnodig. Een goede javascript programmeur kan dingen doen die jij nooit voor mogelijk had gehouden maar een serverside programmeur die javascript 'erbij' doet produceert in veel gevallen verschrikkelijke gedrochten met allerlei crossbrowser issues.

Ik vind dat een goede programeur in beide kanten perfect moet beheersen, wil hij een goede webapp kunnen afleveren.

[BCC]

JKVA schreef op woensdag 15 augustus 2007 @ 11:12:
Ik zie tegenwoordig front end development zelfs als complexer dan back end development, omdat je veel meer flows in je code krijgt. Bij eend back end kun je zelf alle regels bepalen wat het gemakkelijker maakt dan bij front ends waar je vast zit aan enorm veel randvoorwaarden.

Tja, dan ben je IMHO niet helemaal lekker bezig . Een goede backend levert een goede flow voor de frontend. Je frontend moet eigenlijk niet meer doen dan vragen stellen aan de backend die hem dan een bepaalde flow laat doorlopen. Zo blijft je client ook zo dun mogelijk: die doet alleen maar wat er serverside gezegd wordt. Natuurlijk moet je wel de flows testen vanuit de frontend (wat inderdaad niet eenvoudig is), maar volgens mij wil je dingen als een flow in een applicatie altijd serverside bepalen.

[ Voor 17% gewijzigd door BCC op 15-08-2007 11:57 ]

[BCC]

Niemand_Anders schreef op woensdag 15 augustus 2007 @ 08:59:
Wij (het bedrijf waar ik werk) geven meestal de voorkeur aan een gecompileerde taal. Waarom? Omdat een programmeur op een productie website dan niet 'even snel' een regel code kan toevoegen. Iets wat regelmatig gebeurde bij asp, php en perl websites met alle gevolgen van dien. Ook ik heb mij daar weleens schuldig aan gemaakt.

Sorry, maar meen je nou serieus dat een falend release beleid komt door een taalkeuze ? De reden dat wij van Java naar Ror gaan is omdat je helemaal gek wordt van het opnieuw moeten compilen van je complete project omdat je één extra divje heb toegevoegd in je view. De development snelheid is hierdoor ENORM gestegen.

Maar er zijn ook genoeg bedrijven welke zich beperken tot apache en php. Er bestaat (nog) geen ideale programmeer taal op platform. Elk bedrijf/programmeur zal daarin een keuze moeten maken. Die keuze wordt eenvoudig als je meerdere talen beheerst.

Eens

[ Voor 3% gewijzigd door BCC op 15-08-2007 11:58 ]

[OkkE]

BCC schreef op woensdag 15 augustus 2007 @ 11:41:
True, maar volgens mij is het absoluut niet te scheiden. Iedereen doet zijn best om vorm en functie te scheiden, maar het is volgens mij absoluut onmogelijk: je kan best een heel slim formulier hebben, maar als de user door 48 schermpjes moet klikken om er te komen, dan een onhandig forumulier op pagina 1 best een betere oplossing zijn. Volgens mij moet je expert op beide vlakken zijn als je goede software wilt kunnen afleveren.

Je kunt het - in de meeste gevallen - prima scheiden. Er is alleen meer kennis (en vaak ook tijd) voor nodig.
Wat je met je voorbeeld bedoelt te zeggen, ontgaat me in dit geval even. 48 schermpjes (overdreven, maar ok..) door moeten klikken kan soms handig zijn, in een ander geval kan het juist prettiger zijn als het op één pagina staat. Dit is iets wat in mijn ogen onder de functie valt.

Ik vind dat een goede programeur in beide kanten perfect moet beheersen, wil hij een goede webapp kunnen afleveren.

In mijn ogen kun je beide niet perfect beheersen. Tenminste, om dat te kunnen doen moet je er zo ontzettend veel tijd in steken, dat het bijna onhaalbaar is. Daarom ook, ben ik van mening dat front-end en back-end twee losse expertises zijn, die door verschillende mensen gedaan (moeten) worden, om een goede webapp. te maken.
Dat de persoon voor het back-end kennis heeft van front-end en andersom, lijkt me zeker van belang.

[BCC]

OkkE schreef op woensdag 15 augustus 2007 @ 11:57:
Je kunt het - in de meeste gevallen - prima scheiden. Er is alleen meer kennis (en vaak ook tijd) voor nodig.
Wat je met je voorbeeld bedoelt te zeggen, ontgaat me in dit geval even. 48 schermpjes (overdreven, maar ok..) door moeten klikken kan soms handig zijn, in een ander geval kan het juist prettiger zijn als het op één pagina staat. Dit is iets wat in mijn ogen onder de functie valt.

In mijn ogen is de flow in een applicatie altijd een combinatie van vorm en functie. Dit kun je niet los zien. Je kunt ze wel apart designen en schrijven, maar de klant gaat ze altijd tegelijk gebruiken.

In mijn ogen kun je beide niet perfect beheersen. Tenminste, om dat te kunnen doen moet je er zo ontzettend veel tijd in steken, dat het bijna onhaalbaar is. Daarom ook, ben ik van mening dat front-end en back-end twee losse expertises zijn, die door verschillende mensen gedaan (moeten) worden, om een goede webapp. te maken.
Dat de persoon voor het back-end kennis heeft van front-end en andersom, lijkt me zeker van belang.

Dat laatste ben ik het zeker mee eens, het eerste niet (zie ook andere reactie van mij hierboven).

[ Voor 5% gewijzigd door BCC op 15-08-2007 12:02 ]

[JKVA]

BCC schreef op woensdag 15 augustus 2007 @ 11:45:
[...]

Tja, dan ben je IMHO niet helemaal lekker bezig . Een goede backend levert een goede flow voor de frontend. Je frontend moet eigenlijk niet meer doen dan vragen stellen aan de backend die hem dan een bepaalde flow laat doorlopen. Zo blijft je client ook zo dun mogelijk: die doet alleen maar wat er serverside gezegd wordt. Natuurlijk moet je wel de flows testen vanuit de frontend (wat inderdaad niet eenvoudig is), maar volgens mij wil je dingen als een flow in een applicatie altijd serverside bepalen.

Ik denk dat het wel zo werkt. Een service is iets wat een bedrijf doet. Dat staat los van wat voor weergave dan ook. Daarvoor kun je altijd iets van een facade met DTO's ofzo hangen ter ondersteuning van de client (de weblaag dus). Als je dat niet doet, krijg je een logische afhankelijkheid van de weblaag.

En met complexe flows bedoel ik de verschillende paden die een gebruiker kan bewandelen (direct url openen, refreshen, back, forward, dubbelklikken).

- Een service is veel meer rechttoe rechtaan. Je begint, je postcondities heb je in je use case al uitgewerkt en daar kun je rekening mee houden. Je logica is ook bekend.
- Een gebruiker kan niet ineens 2x een service aanroepen, en als dat wel gebeurt is dat de fout van de weblaag.
- Een service geeft gewoon fouten terug als er iets misgaat. De weblaag heeft die luxe niet, die moet ervoor zorgen dat de fout op een -voor de gebruiker- nette manier afgehandeld wordt.

Ofwel, front end development is zeker serieuze business en dat wordt tegenwoordig door veel mensen opgemerkt. Dat zie je ook in vacatures en zo.

[FragFrog]

JKVA schreef op woensdag 15 augustus 2007 @ 12:54:
Ofwel, front end development is zeker serieuze business en dat wordt tegenwoordig door veel mensen opgemerkt. Dat zie je ook in vacatures en zo.

Zeker waar, ben toevallig zelf afgelopen weken aan het solliciteren geweest en daarbij wordt toch wel geregeld gevraagd of ik liever frontend of backend develop. In mijn geval is dat vooral backend trouwens, ik kan me wel redden met javascript en css maar het kost me tijd, pijn en moeite, gezien de snelheid van de ontwikkelingen ben ik het dan ook wel eens met de uitspraak dat je niet zowel frontend als backend perfect kan beheersen, of je moet je heel erg gaan specialiseren (wat in mijn opinie betekend dat je het alsnog niet beide beheerst maar slechts een subset).

Vroegah was het nog wel te doen, maar er zijn zoveel browserquircks, zoveel rare regeltjes om rekening mee te houden dat specialisatie in een kant veel efficienter wordt. Zo kwam ik er laatst achter dat als je een pagina altijd minimaal de hoogte van je scherm wilt geven je in firefox specifiek je html tag 'height: 100%;' moet meegeven - heeft me ruim een uur gekost om dat te verzinnen. Iemand die zich wel toegelegd heeft op frontend development weet zoiets en flift 't er zo tussen. Toegegeven, uiteindelijk kom je er wel (zeker als je maar goed zoekt), maar voor een beetje webdesignbureau is het dan veel rendabeler specifiek iemand op backend of frontend development te zetten.

Vind ik trouwens ook alleen maar mooi, heb stiekem een hekel aan javascript en CSS geneuzel

[BCC]

JKVA schreef op woensdag 15 augustus 2007 @ 12:54:
[...]

En met complexe flows bedoel ik de verschillende paden die een gebruiker kan bewandelen (direct url openen, refreshen, back, forward, dubbelklikken).

Ik ook

- Een service is veel meer rechttoe rechtaan. Je begint, je postcondities heb je in je use case al uitgewerkt en daar kun je rekening mee houden. Je logica is ook bekend.
- Een gebruiker kan niet ineens 2x een service aanroepen, en als dat wel gebeurt is dat de fout van de weblaag.
- Een service geeft gewoon fouten terug als er iets misgaat. De weblaag heeft die luxe niet, die moet ervoor zorgen dat de fout op een -voor de gebruiker- nette manier afgehandeld wordt.
Ofwel, front end development is zeker serieuze business en dat wordt tegenwoordig door veel mensen opgemerkt. Dat zie je ook in vacatures en zo.

Prima, maar je gaat er nu van uit dat de requirements voor je backend service helemaal beschikbaar zijn en perfect zijn en volledig losstaan van je frontend. Iets wat volgens mij een utopie is. Wat ik dus net aangaf is dat je er vaak pas in het frontend design samen met de klant achterkomt dat je front-end niet het probleem is, maar je backend. Die situatie die jij schetst gaat prima op voor een simple frontend op een databaseje. Als het echter iets ingewikkelder wordt, dan wordt het allemaal een stuk complexer (in interessanter).

[JKVA]

BCC schreef op woensdag 15 augustus 2007 @ 16:07:
[...]

Ik ook

[...]

Prima, maar je gaat er nu van uit dat de requirements voor je backend service helemaal beschikbaar zijn en perfect zijn en volledig losstaan van je frontend. Iets wat volgens mij een utopie is. Wat ik dus net aangaf is dat je er vaak pas in het frontend design samen met de klant achterkomt dat je front-end niet het probleem is, maar je backend. Die situatie die jij schetst gaat prima op voor een simple frontend op een databaseje. Als het echter iets ingewikkelder wordt, dan wordt het allemaal een stuk complexer (in interessanter).

True, en ik heb het ook over ingewikkelde zaken. Bijvoorbeeld banken, waar ze serieus werken aan een nette infrastructuur. En dan merk je dat er niet in schermen gedacht wordt, maar in services.

Services die ouwe ASS400 backends ontsluiten, nieuwe services voor een specifiek domein zoals contracten, klanten, hypotheken, etc. En dat sluit niet aan op één specifieke applicatie. Vaak zijn er vele applicaties die op dezelfde services werken, of meerdere services die input leveren voor één applicatie. Kijk maar naar portals. Die werken helemaal volgens dergelijken ideëen.

Maar misschien werk ik wel in een compleet andere tak dan jij. Ik zit zelf voornamlijk bij top40/overheid en daar zie je wel degelijk serieuze IT.

Afhankelijk van de manier waarop je in het project werkt, architectuur opzet, requirements opstelt, functioneel ontwerpt en dergelijke is het wel of geen utopie. En nee, ik ben geen filosoof die alles tussen web en service gescheiden wil hebben. Als je twee vergelijkbare oplossingsrichtingen hebt en de ene is gemakkelijker om in een GUI mee te werken (bijvoorbeeld in het kader van i18n) dan kies ik natuurlijk ook die optie.

[BCC]

JKVA schreef op woensdag 15 augustus 2007 @ 16:48:
Services die ouwe ASS400 backends ontsluiten, nieuwe services voor een specifiek domein zoals contracten, klanten, hypotheken, etc. En dat sluit niet aan op één specifieke applicatie. Vaak zijn er vele applicaties die op dezelfde services werken, of meerdere services die input leveren voor één applicatie. Kijk maar naar portals. Die werken helemaal volgens dergelijken ideëen.

Maar misschien werk ik wel in een compleet andere tak dan jij. Ik zit zelf voornamlijk bij top40/overheid en daar zie je wel degelijk serieuze IT.

Ah, de trage IT Waar de klant eerst alles keihard specificeert, dat vervolgens geprogt wordt en dat dan uiteindelijk blijkt dat de klant het verkeerde probleem gespecificeert heeft en eigenlijk helemaal niet kan specificeren .

Ik zit bij de top 10 healthcare oplossingen. Daar is het een stuk meer rapid development / extreme programming: de klant zegt A, wij leveren prototype B omdat wij denk dat dat het wel zal zijn en komen er dan tijdens de pilot achter dat de klant C bedoelt en schrijven wel snel alles om en leveren dat dan. Vooral omdat de klant helemaal geen idee heeft wat z'n echte probleem is en hoe hij/zij het moet oplossen.

Afhankelijk van de manier waarop je in het project werkt, architectuur opzet, requirements opstelt, functioneel ontwerpt en dergelijke is het wel of geen utopie. En nee, ik ben geen filosoof die alles tussen web en service gescheiden wil hebben. Als je twee vergelijkbare oplossingsrichtingen hebt en de ene is gemakkelijker om in een GUI mee te werken (bijvoorbeeld in het kader van i18n) dan kies ik natuurlijk ook die optie.

Als je vanuit het toch ondertussen wel wat ouderwetse waterval model denkt, moet ik je helemaal gelijk geven. Vanuit de nu hippe extreme programming en rapid development kant niet.

[ Voor 4% gewijzigd door BCC op 15-08-2007 16:55 ]

[Verwijderd]

BCC schreef op woensdag 15 augustus 2007 @ 16:54:
Als je vanuit het toch ondertussen wel wat ouderwetse waterval model denkt, moet ik je helemaal gelijk geven. Vanuit de nu hippe extreme programming en rapid development kant niet.

Hoe jij je interne ontwikkeling ook inricht, niet elke klant zit te wachten op een Agile methode. Tevens is niet elk bedrijf in de positie om de krenten uit de pap te kiezen wat klanten betreft. Het heeft dus helemaal niks te maken hoe andere ontwikkelaars 'denken' maar vooral wat je klantenbestand is.

[BCC]

Verwijderd schreef op woensdag 15 augustus 2007 @ 17:02:
[...]
Hoe jij je interne ontwikkeling ook inricht, niet elke klant zit te wachten op een Agile methode. Tevens is niet elk bedrijf in de positie om de krenten uit de pap te kiezen wat klanten betreft. Het heeft dus helemaal niks te maken hoe andere ontwikkelaars 'denken' maar vooral wat je klantenbestand is.

Dat is niet helemaal waar. Er zijn genoeg bedrijven die in een agile markt een watervalmodel proberen te hanteren. Dit gaat dan ook vaak hard mis. Ik snap ook wel dat je een Belastingsdienst koppeling niet Agile wil developen

[Verwijderd]

BCC schreef op woensdag 15 augustus 2007 @ 17:21:
Dat is niet helemaal waar.

Wat is er niet waar aan? Je kunt nou eenmaal niet (volledig) Agile gaan werken bij een klant die simpelweg iets anders van je verlangt. Misschien is je bedrijf niet flexibel genoeg om ook met dergelijke klanten om te gaan of wil deze zich graag op een andere manier positioneren. Hoe het ook zij, hoe mensen in een project zitten ligt meestal meer aan de klanten dan aan de persoon zelf.

BCC schreef op woensdag 15 augustus 2007 @ 17:21:
Er zijn genoeg bedrijven die in een agile markt een watervalmodel proberen te hanteren.

Welke nitwit heeft je deze onzin ingefluisterd?

[BCC]

[quote]Verwijderd schreef op woensdag 15 augustus 2007 @ 18:11:
[...]
Wat is er niet waar aan?
Ik reageerde op:

Het heeft dus helemaal niks te maken hoe andere ontwikkelaars 'denken' maar vooral wat je klantenbestand is.

Volgens mij zijn er een heleboel vastgeroeste ontwikkelaars. Die in de verkeerde markten verkeerde dingen doen.

[JKVA]

BCC schreef op woensdag 15 augustus 2007 @ 16:54:
[...]
Als je vanuit het toch ondertussen wel wat ouderwetse waterval model denkt, moet ik je helemaal gelijk geven. Vanuit de nu hippe extreme programming en rapid development kant niet.

Bij agile is het juist de bedoeling dat je netjes werkt. Dat is zelfs één van de core principes.
"Continuous attention to technical excellence and good design enhances agility."

Ook is één van de principes dat je met business op één lijn zit.
"Business people and developers must work together daily throughout the project."

http://agilemanifesto.org/principles.html

Mijn opmerking heeft dus helemaal niets met waterval te maken. Het heeft wel te maken met het feit dat back ends en front ends compleet verschillende dingen zijn waar compleet verschillende regels gelden.

Maar goed, deze discussie ontspoort, dus ik nok hiermee.

BCC schreef op woensdag 15 augustus 2007 @ 21:21:
[quote]Verwijderd schreef op woensdag 15 augustus 2007 @ 18:11:
[...]
Wat is er niet waar aan?
Ik reageerde op:

[...]

Volgens mij zijn er een heleboel vastgeroeste ontwikkelaars. Die in de verkeerde markten verkeerde dingen doen.

Ik denk dat er veel meer vastgeroeste projectmanagers zijn. Ontwikkelaars zijn het volgens mij allang kotsbeu dat ze dingen keer op keer opnieuw moeten bouwen. Projectleiders, aan de andere kant, willen alles tot het einde van het jaar inplannen, want dat geeft ze de indruk dat ze de boel onder controle hebben.

[eamelink]

crisp schreef op woensdag 15 augustus 2007 @ 11:07:
Bij veel mensen leeft nog steeds het idee dat javascript een 'simpel taaltje' is dat prima door een of andere serverside tool gegenereerd kan worden. Daarmee doe je ten eerste de taal zelf tekort en je beperkt jezelf onnodig.

De taal zelf is inderdaad zeer rijk aan features. Echter, Javascript wordt vrijwel exclusief gebruikt voor relatief simpele dingen. Bij een gemiddelde applicatie is de serverside code vele malen complexer en omvangrijker dan het Javascript werk .

Een goede javascript programmeur kan dingen doen die jij nooit voor mogelijk had gehouden maar een serverside programmeur die javascript 'erbij' doet produceert in veel gevallen verschrikkelijke gedrochten met allerlei crossbrowser issues.

Tuurlijk kan een javascript programmeur verschrikkelijk mooie dingen maken, maar ook voor die javascript programmeur geldt dat hij tegen allerlei problemen oploopt (traagheid van JS implementaties, verschillende browsers), die zijn serverside collega niet heeft.

Daar komt bij dat recente libraries als MooTools door een serverside programmeur in enkele dagen onder de knie gekregen kan worden, waarmee hij (of zij ) prima code kan schrijven, die werkt in alle moderne browsers. Tel daarbij op dat de complexiteit van de benodigde javascript over het algemeen niet zo groot is, en dan denk ik dat je best kunt zeggen dat een serverside programmeur over het algemeen het javascript werk erbij kan pakken. Natuurlijk zijn er altijd uitzonderingen, maar ik vermoed dat een doorgewinterde Cake PHP programmeur vlotjes met MooTools aan de slag kan, terwijl dat andersom best eens desastreus zou kunnen worden

[crisp]

hèhè, eindelijk weer ontopic

eamelink schreef op donderdag 16 augustus 2007 @ 21:48:
[...]

De taal zelf is inderdaad zeer rijk aan features. Echter, Javascript wordt vrijwel exclusief gebruikt voor relatief simpele dingen. Bij een gemiddelde applicatie is de serverside code vele malen complexer en omvangrijker dan het Javascript werk .

Een paar jaar geleden had ik je gelijk gegeven maar tegenwoordig zijn sites die complexe dingen met javascript doen geen uitzondering meer. De hele vlucht die "Ajax" heeft genomen en de "Web 2.0 hype/movement" hebben clientside webdevelopment een behoorlijk push gegeven (en dat is op zich niet verkeerd imo).

[...]

Tuurlijk kan een javascript programmeur verschrikkelijk mooie dingen maken, maar ook voor die javascript programmeur geldt dat hij tegen allerlei problemen oploopt (traagheid van JS implementaties, verschillende browsers), die zijn serverside collega niet heeft.

In de eerste plaats kies je uiteraard voor bepaalde clientside-based oplossingen om een reden (nou ja, sommige mensen denken dat bepaalde technieken zoals Ajax een soort van silver bullet is en gebruiken het ook waar het niet nuttig is).
Uiteraard is de "always post-back" methode een behoorlijk simpele en daarmee zal je inderdaad niet zo snel tegen specifieke problemen aanlopen waar je met clientside scripting zeker tegenaan gaat lopen; de vraag die je dus altijd moet stellen is of het gebruik van clientside technieken voldoende meerwaarde biedt tegenover de kosten. Maar ook hier geldt dat met de juiste kennis en ervaring die kosten steeds lager uit zullen vallen.

Daar komt bij dat recente libraries als MooTools door een serverside programmeur in enkele dagen onder de knie gekregen kan worden, waarmee hij (of zij ) prima code kan schrijven, die werkt in alle moderne browsers.

Het probleem met libraries is dat je jezelf een bepaalt paradigma aanleert en niet de taal zelf. Als je dan net even verder wil gaan dan wat een library je aan mogelijkheden biedt hang je al (genoeg topics in WEB om dat te bewijzen). Daarbij zijn libraries abstracties, en abstracties lekken. Sommige libraries gaan zover in hun queste om alle crossbrowser issues weg te abstraheren dat daarmee performance juist een issue wordt, en ik kan nog wel even doorgaan op dat vlak - er is imo geen perfecte JS library.

Tel daarbij op dat de complexiteit van de benodigde javascript over het algemeen niet zo groot is, en dan denk ik dat je best kunt zeggen dat een serverside programmeur over het algemeen het javascript werk erbij kan pakken. Natuurlijk zijn er altijd uitzonderingen, maar ik vermoed dat een doorgewinterde Cake PHP programmeur vlotjes met MooTools aan de slag kan, terwijl dat andersom best eens desastreus zou kunnen worden

Zolang je niet hoeft af te wijken van wat simpele form-validaties in JS denk ik dat je gelijk hebt (hoewel de meeste serverside programmeurs zelfs dat niet eens netjes kunnen in JS). Het ligt er ook helemaal aan wat voor soort sites of webapplicaties je bouwt en voor welke doelgroep. Ik denk echter wel dat je jezelf behoorlijk beperkt door niet naar clientside enrichments te kijken.

[Erkens]

eamelink schreef op donderdag 16 augustus 2007 @ 21:48:
De taal zelf is inderdaad zeer rijk aan features. Echter, Javascript wordt vrijwel exclusief gebruikt voor relatief simpele dingen. Bij een gemiddelde applicatie is de serverside code vele malen complexer en omvangrijker dan het Javascript werk .

Ik ben blij dat je het over een "gemiddelde" applicatie hebt, hoewel ik alsnog daar mijn twijfels bij heb. Neem bijvoorbeeld de webapplicatie waar ik op mijn werk mee bezig ben (email/groupware applicatie). Dit is gebaseerd op een PHP backend welke niks anders doet dan XML opbouwen vanuit MAPI en weer terug en dit dan naar de browser sturen. Relatief simpel dus, echter daarna moet vanuit de client iets met deze data gedaan worden.

Wat mij meteen op het volgende punt brengt.

Tuurlijk kan een javascript programmeur verschrikkelijk mooie dingen maken, maar ook voor die javascript programmeur geldt dat hij tegen allerlei problemen oploopt (traagheid van JS implementaties, verschillende browsers), die zijn serverside collega niet heeft.

De "nadelen" die je noemt wegen namelijk niet altijd op tegen de voordelen: snellere user response.
Een gebruiker van een applicatie wilt namelijk niet wachten tot de volgende pagina geladen is bijvoorbeeld. Neem alleen maar even het nieuwe moderatie systeem op de t.net frontpage. Je hoeft niet nog een keer op een knop te drukken om het te bevestigen maar de gegevens zijn direct verstuurd en je ziet ook meteen het resultaat van je actie.

Maar om dergelijke systemen goed te implementeren is er wel wat meer kennis en ervaring nodig dan even "simpel" een random framework pakken en online zetten.

[killercow]

ClientSide programmeren bestaat uit zo veel laagjes van "verlichting" dat ik me niet goed kan voorstellen dat een serverside programmeur dit zo maar onder de knie krijgt.

Met deze laagjes bedoel ik bijvoorbeeld:
Css ipv inline styles, en daarna het hele idee "cascading" binnen css, css speed optimalisaties.
Table-less design
Semantisch correcte elementen icm semantische correcte css.
Javascript -> unobstrusive javascript -> object georienteerde javascript

En dan inderdaad nog de SEO optimalisaties, URL rewrites, cross-browser problemen en mogelijkheden, de verschillende usability guidelines icm met screenreaders, text browsers etc.

Het zijn zelfs zo veel haakjes en ogen dat je vaak voor een project niet een alles netjes aan alles kunt voldoen binnen een bepaald budget.

Al die stapjes maak je als developper gaandeweg mee, dit komt vooral omdat de eerste versie ook prima werkt, en je niet goed het voordeel van al die "poespas" inziet tot je projecten groter en ingewikkelder worden.

[ Voor 3% gewijzigd door killercow op 17-08-2007 16:41 ]

[JKVA]

killercow schreef op vrijdag 17 augustus 2007 @ 16:40:
ClientSide programmeren bestaat uit zo veel laagjes van "verlichting" dat ik me niet goed kan voorstellen dat een serverside programmeur dit zo maar onder de knie krijgt.

Met deze laagjes bedoel ik bijvoorbeeld:
Css ipv inline styles, en daarna het hele idee "cascading" binnen css, css speed optimalisaties.
Table-less design
Semantisch correcte elementen icm semantische correcte css.
Javascript -> unobstrusive javascript -> object georienteerde javascript

En dan inderdaad nog de SEO optimalisaties, URL rewrites, cross-browser problemen en mogelijkheden, de verschillende usability guidelines icm met screenreaders, text browsers etc.

Het zijn zelfs zo veel haakjes en ogen dat je vaak voor een project niet een alles netjes aan alles kunt voldoen binnen een bepaald budget.

Al die stapjes maak je als developper gaandeweg mee, dit komt vooral omdat de eerste versie ook prima werkt, en je niet goed het voordeel van al die "poespas" inziet tot je projecten groter en ingewikkelder worden.

Ik merk zojuist weer hetzelfde. Een jaar of twee geleden kon ik vrij aardig CSS en layouts maken. Nu wil ik een paar simpele dingen een beetje op de goede plaats zetten, lukt het niet meer. De front end wereld is zo snel in beweging. Voor iemand die er niet full time mee bezig is, is het gewoonweg niet bij te houden. Zeker niet als je alle browser specifieke quirks en zo mee gaat tellen.

[BCC]

JKVA schreef op vrijdag 17 augustus 2007 @ 17:04:
[...]

Ik merk zojuist weer hetzelfde. Een jaar of twee geleden kon ik vrij aardig CSS en layouts maken. Nu wil ik een paar simpele dingen een beetje op de goede plaats zetten, lukt het niet meer. De front end wereld is zo snel in beweging. Voor iemand die er niet full time mee bezig is, is het gewoonweg niet bij te houden. Zeker niet als je alle browser specifieke quirks en zo mee gaat tellen.

Grappig, ik zie het juist andersom. Door frameworks als prototype en scriptaculous worden de meeste browser quirks afgevangen door het framework, waardoor je als developer sneller betere dingen kan bouwen. Hetzelfde geld voor CSS, sinds IE7 redelijk aan standaarden voldoet is het vrij eenvoudig om een pagina er fatsoenlijk uit te laten zien in IE7, Firefox, Safari en Opera.

[Erkens]

BCC schreef op vrijdag 17 augustus 2007 @ 18:03:
Grappig, ik zie het juist andersom. Door frameworks als prototype en scriptaculous worden de meeste browser quirks afgevangen door het framework, waardoor je als developer sneller betere dingen kan bouwen.

Je weet alleen niet meer waar je nu werkelijk mee bezig bent, en dan heb ik het nog niet eens over hoe bloated vele van die frameworks zijn, iets wat doorgaands de snelheid niet ten goede komt

Hetzelfde geld voor CSS, sinds IE7 redelijk aan standaarden voldoet is het vrij eenvoudig om een pagina er fatsoenlijk uit te laten zien in IE7, Firefox, Safari en Opera.

IE7 voldoet redelijk aan de standaarden? Ja, Microsofts standaarden wellicht Daarnaast vergeet je gewoon even IE6? afaik nog steeds de meest gebruikte browser.

[JKVA]

Erkens schreef op vrijdag 17 augustus 2007 @ 18:23:
[...]

Je weet alleen niet meer waar je nu werkelijk mee bezig bent, en dan heb ik het nog niet eens over hoe bloated vele van die frameworks zijn, iets wat doorgaands de snelheid niet ten goede komt


[...]

IE7 voldoet redelijk aan de standaarden? Ja, Microsofts standaarden wellicht Daarnaast vergeet je gewoon even IE6? afaik nog steeds de meest gebruikte browser.

Ik probeerde vooral in de context van de discussie te reageren. Wat ik bedoelde was dat ik een paar jaar geleden veel intensiever met CSS en zo werkte dan tegenwoordig. Ik zit tegenwoordig vooral op achterkanten en het beetje front end werk wat ik de laatste tijd gedaan heb, is voornamelijk server side geweest, met af en toe een AJAX uitstapje.

Nu kan ik (vooral op CSS gebied) weer vrijwel from scratch beginnen, behalve dat ik de concepten en zo nog ken. Dat verleer je niet zo snel.

Ofwel, alles gaat erg snel en het is een erg specialistisch gebeuren geworden. Frameworks helpen tot een bepaalde hoogte. Zoals Crisp ook al aangegeven heeft, dwingen frameworks je tot een bepaalde werkwijze. Als je iets afwijkends wilt bereiken, sta je machteloos als je niet genoeg kennis hebt van JS, CSS, DOM, HTML, etc...

Overigens speelt dit laatste ook serverside. Ik heb genoeg mensen gezien die (Java voorbeeld) pretendeerden senior Hibernate ontwikkelaar te zijn, maar simpelweg de kennis van SQL en databases misten om er op een verantwoordelijke manier mee te werken. Ok, ze kenden de elementen uit de mapping file uit hun hoofd. Joepieeeeee, maar van indexen of iets complexere queries hadden ze geen kaas gegeten. Lekker verhaal als je performance problemen hebt op de productieserver.

[Erkens]

JKVA schreef op vrijdag 17 augustus 2007 @ 20:02:
Ik probeerde vooral in de context van de discussie te reageren. Wat ik bedoelde was dat ik een paar jaar geleden veel intensiever met CSS en zo werkte dan tegenwoordig.
<knip>
Ofwel, alles gaat erg snel en het is een erg specialistisch gebeuren geworden. Frameworks helpen tot een bepaalde hoogte. Zoals Crisp ook al aangegeven heeft, dwingen frameworks je tot een bepaalde werkwijze. Als je iets afwijkends wilt bereiken, sta je machteloos als je niet genoeg kennis hebt van JS, CSS, DOM, HTML, etc...

Precies, maar toch denken veel mensen er te makkelijk over. En dan heb ik het niet alleen over opdrachtgevers, maar vooral over developers die alleen bezig zijn met de backend en af en toe wat in elkaar prakken voor de client.

Overigens speelt dit laatste ook serverside. Ik heb genoeg mensen gezien die (Java voorbeeld) pretendeerden senior Hibernate ontwikkelaar te zijn, maar simpelweg de kennis van SQL en databases misten om er op een verantwoordelijke manier mee te werken. Ok, ze kenden de elementen uit de mapping file uit hun hoofd. Joepieeeeee, maar van indexen of iets complexere queries hadden ze geen kaas gegeten. Lekker verhaal als je performance problemen hebt op de productieserver.

Uiteraard speelt dat onderdeel daar ook, alleen wordt het aan die kant vaak gewoon geaccepteerd, terwijl de frontend toch echt het ding is waar de eindgebruikers mee te maken krijgen.

[Victor]

BCC schreef op dinsdag 14 augustus 2007 @ 23:28:
Nou kan de rest van je team natuurlijk de backend ontwikkelen en jij de frontend, maar dat is volgens mij wederom niet goed voor je eigen positie.

Laat ik nou in een web development team werken als senior client-side web developer. Wij hebben die scheiding zeer goed aan kunnen brengen: vormgeving levert een design aan, server-side levert functionaliteit aan en ik en mijn collega klussen er een werkende interface aan vast.

Maakt dat mij een minder vitaal onderdeel van het ontwikkelproces? Mijn server-side collega's kunnen echt mijn werk niet over nemen, net zo min als dat ik hun werk er even "bij" zou kunnen doen. Als je met een beetje flink tempo wil door ontwikkelen heb je gewoon mensen nodig die zich specialiseren op één vakgebied. En client-side development is een vakgebied op zich.

[BCC]

King_Louie schreef op vrijdag 17 augustus 2007 @ 20:53:
[...]

Laat ik nou in een web development team werken als senior client-side web developer. Wij hebben die scheiding zeer goed aan kunnen brengen: vormgeving levert een design aan, server-side levert functionaliteit aan en ik en mijn collega klussen er een werkende interface aan vast.

Natuurlijk kan het wel, maar je moet wel erg goed overleggen en strak samenwerken met je server-side collega's om bruikbare applicaties op te leveren. Maar zoals eerder al gezegd: Dit ligt ook erg aan de soort software die je schrijft. Bij mij zou dat nl. voor sommige gedeeltes absoluut onmogelijk zijn.

[Janoz]

Je moet altijd goed overleggen en strak samenwerken. Dat is bij andere samenwerkingen hetzelfde. Het is gewoon van belang dat je van elkaar weet wat de mogelijkheden en de restricties zijn. Belangrijk is dat je vooral geen aannames maakt over wat aan de andere kant wel zou of niet zou kunnen zonder dat te vragen en aan de andere kant is het ook van belang deze vragen niet als vervelend te ervaren.

Het grootste probleem bij samenwerkingen tussen frontend en backend klussers is dat er geen wederzijds respect bestaat. Voorkant is maar een beetje simpel photoshopen en html klussen en de achterkant is niks meer dan een beetje wat querie resultaten omzetten in onmogelijke html.

[BCC]

Erkens schreef op vrijdag 17 augustus 2007 @ 18:23:
Je weet alleen niet meer waar je nu werkelijk mee bezig bent, en dan heb ik het nog niet eens over hoe bloated vele van die frameworks zijn, iets wat doorgaands de snelheid niet ten goede komt

Jij gebruikt zeker ook nog een zelfgeschreven webserver in C? Frameworks als scriptaculous en prototype zijn tegenwoordig enorm snel, bevatten alle functies die je ooit zou willen gebruiken en zorgen voor mooie gestructureerde code. Natuurlijk kun je het altijd zelf beter, maar waarom zou je het wiel nog een keer uitvinden terwijl anderen dat al een stuk beter hebben gedaan?

[ Voor 3% gewijzigd door BCC op 20-08-2007 11:08 ]

[killercow]

BCC schreef op maandag 20 augustus 2007 @ 11:07:
[...]

Jij gebruikt zeker ook nog een zelfgeschreven webserver in C? Frameworks als scriptaculous en prototype zijn tegenwoordig enorm snel, bevatten alle functies die je ooit zou willen gebruiken en zorgen voor mooie gestructureerde code. Natuurlijk kun je het altijd zelf beter, maar waarom zou je het wiel nog een keer uitvinden terwijl anderen dat al een stuk beter hebben gedaan?

En toch verneukt bijvoorbeeld protype het hele array object, je pint je zelf dus vast in en bepaalde hoek en tjah je krijgt er wat voor terug, maar wat zijn de bijwerkingen?
Het mooie aan webservers is dat er specs zijn, elke webserver die zich aan de spec houdt kan je in principe gebruiken, http is gewoon beschreven, en met elke websever kun je in principe elke http actie uitvoeren.

[BikkelZ]

killercow schreef op maandag 20 augustus 2007 @ 11:37:
[...]

En toch verneukt bijvoorbeeld protype het hele array object, je pint je zelf dus vast in en bepaalde hoek en tjah je krijgt er wat voor terug, maar wat zijn de bijwerkingen?
Het mooie aan webservers is dat er specs zijn, elke webserver die zich aan de spec houdt kan je in principe gebruiken, http is gewoon beschreven, en met elke websever kun je in principe elke http actie uitvoeren.

De meeste mensen die met Prototype werken werken met Prototype omdat ze JavaScript niet begrijpen. Dan heb je mensen die perfect kunnen PHP'en, en die krijgen dan zo'n glazige eindgebruikersblik als je ze probeert uit te leggen wat het probleem is met Prototype. Gaan ze helemaal in PHP het tienduizendste eigen webframework schrijven en voor JavaScript wordt dan klakkeloos even de marktleider gebruikt zonder enig gedegen onderzoek.

Ik snap dat niet, maar goed.

[Erkens]

BCC schreef op maandag 20 augustus 2007 @ 11:07:
Jij gebruikt zeker ook nog een zelfgeschreven webserver in C? Frameworks als scriptaculous en prototype zijn tegenwoordig enorm snel, bevatten alle functies die je ooit zou willen gebruiken en zorgen voor mooie gestructureerde code. Natuurlijk kun je het altijd zelf beter, maar waarom zou je het wiel nog een keer uitvinden terwijl anderen dat al een stuk beter hebben gedaan?

Wat die server betreft: ja maar dat is weer heel iets anders

Natuurlijk zijn die frameworks snel genoeg, alleen bevatten ze veel meer dan dat je ooit nodig hebt, die meuk moet uiteindelijk toch allemaal bij de client terrecht komen: meer download time -> trager.
Daarnaast zeg ik niet dat ik die frameworks naast me neer leg, nee ik haal eruit wat ik nodig heb en pas dat aan mijn wensen aan.

[crisp]

killercow schreef op maandag 20 augustus 2007 @ 11:37:
[...]

En toch verneukt bijvoorbeeld protype het hele array object [...]

que?

[killercow]

crisp schreef op maandag 20 augustus 2007 @ 12:14:
[...]

que?

http://blog.metawrap.com/...ejsJavaScriptLibrary.aspx
Misschien iets overdreven, maar volgens mij is vooral dit nog niet opgelost.

code:

for(x in object)

[crisp]

killercow schreef op maandag 20 augustus 2007 @ 12:44:
[...]

http://blog.metawrap.com/...ejsJavaScriptLibrary.aspx
Misschien iets overdreven, maar volgens mij is vooral dit nog niet opgelost.

code:

for(x in object)

wat een onzin; ten eerste moet je array's niet misbruiken als hashmap (gebruik dan gewoon een object - prototype extend Object ook niet), en ten tweede dien je in dergelijke loops hasOwnProperty te gebruiken als je niet zeker weet of een Object al dan niet extended is...

Het Array object extenden is al tijden common-practice; bijvoorbeeld om support voor bepaalde methods te backporten (IE5 ondersteunde bijvoorbeeld methods als slice() niet en tegenwoordig is het hip om Mozilla's Array Extra's te porten naar andere browsers).

Common rules:
- Object.prototype is verboten
- Als je for-in denkt nodig te hebben voor een Array dan had je een Object moeten gebruiken

[ Voor 32% gewijzigd door crisp op 20-08-2007 12:58 ]

[killercow]

crisp schreef op maandag 20 augustus 2007 @ 12:50:
[...]


Common rules:
- Object.prototype is verboten
- Als je for-in denkt nodig te hebben voor een Array dan had je een Object moeten gebruiken

Sure, maar t gebeurdt vaak genoeg waardoor je dus in de problemen komt als een of andere niet veel wetende front-ender zomaar prototype ergens in een website gooit voor een effect in z'n mooie menutje.

[crisp]

killercow schreef op maandag 20 augustus 2007 @ 14:10:
[...]


Sure, maar t gebeurdt vaak genoeg waardoor je dus in de problemen komt als een of andere niet veel wetende front-ender zomaar prototype ergens in een website gooit voor een effect in z'n mooie menutje.

prototype extend Object al vanaf versie 1.4 niet meer

Maar goed, het illustreert wel mooi dat je ook niet altijd 100% op libraries moet/kan vertrouwen (afgezien van de andere nadelen)

[ Voor 14% gewijzigd door crisp op 20-08-2007 14:28 ]

[JKVA]

crisp schreef op maandag 20 augustus 2007 @ 14:22:
[...]

prototype extend Object al vanaf versie 1.4 niet meer

Maar goed, het illustreert wel mooi dat je ook niet altijd 100% op libraries moet/kan vertrouwen (afgezien van de andere nadelen)

Maar ja, aan de andere kant heb jij bovengemiddelde JavaScript capaciteiten. Voor de gemiddelde JavaScripter (dus niet alleen de serverside-ik-doe-javascript-er-maar-ff-bij-developer) biedt prototype vele voordelen. En de nadelen die het heeft (zoals performance en andere tweaks) zouden ze in hun eigen code ook tegenkomen, want ze kunnen zelf meestal toch niet efficiënter programmeren dan het prototype team. Het krijgen en onderhouden van JavaScript skills vergt (en dat kan crisp wel beamen, verwacht ik) veel doorzettingsvermogen en vrije tijd, want die markt staat absoluut niet stil.

Tel daar een stukje support bij op. Als MS besluit om in IE8 alles om te gooien, kan de grote community snel en gemakkelijk een patch maken. Bij zelfgemaakte code duurt dit doorgaans langer.

[Verwijderd]

crisp schreef op maandag 20 augustus 2007 @ 14:22:
Maar goed, het illustreert wel mooi dat je ook niet altijd 100% op libraries moet/kan vertrouwen (afgezien van de andere nadelen)

Helemaal mee eens. Dat er breaking upgrades uitgegeven worden moet geen reden zijn om libraries te vermijden. Testen is en blijft heilig met elke vorm van software ontwikkeling.

Maargoed, on-topic. Problemen met JavaScript komen vaak door verschillende interpretaties van browsers. De oorzaak hiervan is het feit dat het een script is. Instructies in de vorm van binaire code sturen heeft het nadeel dat het niet of minder platformonafhankelijk is en de nodige veiligheidsrisico's met zich meebrengt. Dit geldt voor scripts in het algemeen: PHP is net zo goed een script die onderworpen is aan de interpretatie van de (willekeurige) PHP versie die op de server staat. Ik gebruik dus zo min mogelijk JavaScript en geen PHP omdat je als programmeur niets zeker weet over de executie en, even los van het topic, beide zijn untyped en ik hou niet van open source.

Daarom voor mij dus ASP.NET i.c.m. ASP.NET AJAX voor enkele "client side" foefjes waarbij de server het uiteindelijke werk doet. Voor de rest zie ik alleen nut voor JavaScript als het gaat om visuele effecten.

Maargoed, client side is niet enkel JavaScript... Voor HTML, CSS, Flash, design en accessibility heb je, afhankelijk van de site uiteraard, experts nodig. In mijn ogen geen bijbaantje, maar echt een vak. Wat betreft JavaScript: zoveel mogelijk vermijden zoals hierboven uitgelegd.

[farlane]

I

Verwijderd schreef op maandag 20 augustus 2007 @ 15:33:
[...]

Ik snap jouw redenering niet, volgens mij is het complete onzin wat je schrijft.

Waarom zou PHP afhankelijk zijn van een versienummer en ASP.NET niet? En JavaScript is een probleem omdat het een script is? En in welke mate is de ASP.NET code geen script volgens jou?

ik hou niet van open source

Draai dan niet zo om de hete brei heen. Vind het een vrij kortzichtige stelling maargoed.

[BikkelZ]

Verwijderd schreef op maandag 20 augustus 2007 @ 15:33:
[...]Dit geldt voor scripts in het algemeen: PHP is net zo goed een script die onderworpen is aan de interpretatie van de (willekeurige) PHP versie die op de server staat. Ik gebruik dus zo min mogelijk JavaScript en geen PHP omdat je als programmeur niets zeker weet over de executie en, even los van het topic, beide zijn untyped en ik hou niet van open source.

Pfoe, untyped is het enige wat gedeeltelijk klopt. Maar je beseft natuurlijk ook wel net zo goed als mij dat jouw ASP.NET code niet lekker gaat draaien op een NT4 server? Want backwards compatibility daar zijn ze bij Zend en Microsoft allebei net ff iets te goed in, maar forwards compatibility heb ik nog nooit gezien

[gorgi_19]

En daarnaast: M'n ASP.Net 1.1 code vond de runtime van .Net 2.0 ook niet echt plezant en weigerde categorisch om er mee te gaan werken

[Verwijderd]

farlane schreef op maandag 20 augustus 2007 @ 16:05:
Ik snap jouw redenering niet, volgens mij is het complete onzin wat je schrijft.

Waarom zou PHP afhankelijk zijn van een versienummer en ASP.NET niet? En JavaScript is een probleem omdat het een script is? En in welke mate is de ASP.NET code geen script volgens jou?

Wat jij complete onzin noemt is het verschil tussen een script en binaire code met instructies.

ASP.NET compile je tot een DLL, PHP upload je als script en schuif je de interpretatie af op de betreffende PHP installatie op de server. Die PHP module leest gewoon je .php bestand en weet niets van versie informatie. Ik wil .NET niet evangaliseren, maar .NET houdt wél rekening met versies (o.a. met een side by side cache). Bovendien compile je een ASP.NET website tot binaire MSIL instructies en weet de server om welke .NET versie het gaat. PHP gokt een eind weg wat dat betreft. Toegegeven, meestal gaat dat goed. Complete onzin

farlane schreef op maandag 20 augustus 2007 @ 16:05:
Draai dan niet zo om de hete brei heen. Vind het een vrij kortzichtige stelling maargoed.

Als je mijn post beter had gelezen, dan had je eruit opgemaakt dat het feit dat ASP.NET closed source is niet dé reden is om ASP.NET te gebruiken. Bovendien is dat zoals ik zei off-topic.

gorgi_19 schreef op maandag 20 augustus 2007 @ 16:19:
En daarnaast: M'n ASP.Net 1.1 code vond de runtime van .Net 2.0 ook niet echt plezant en weigerde categorisch om er mee te gaan werken

Dan heb je IIS verkeerd ingesteld. ASP.NET 1.1 en 2.0 draaien naadloos naast elkaar, evenals allerlei release candidates en betas.

BikkelZ schreef op maandag 20 augustus 2007 @ 16:17:
[...]
Maar je beseft natuurlijk ook wel net zo goed als mij dat jouw ASP.NET code niet lekker gaat draaien op een NT4 server? Want backwards compatibility daar zijn ze bij Zend en Microsoft allebei net ff iets te goed in, maar forwards compatibility heb ik nog nooit gezien

Niet backward compatible? In de documentatie van .NET is bij elke class en method te vinden op welk platform deze wel of niet ondersteund wordt. .NET is nou eenmaal een framework op een besturingssysteem. En als dat besturingssysteem even iets niet ondersteunt, dan staat dat netjes gedocumenteerd. Ik zie je probleem niet.

Niet forward compatible? ASP.NET 1.1 draait moeiteloos op Windows Server 2003.

Geen idee dus wat je bedoelt.

[ Voor 32% gewijzigd door Verwijderd op 20-08-2007 16:29 . Reden: reacties toegevoegd ]

[killercow]

Verwijderd schreef op maandag 20 augustus 2007 @ 16:23:
[...]

Wat jij complete onzin noemt is het verschil tussen een script en binaire code met instructies.

ASP.NET compile je tot een DLL, PHP upload je als script en schuif je de interpretatie af op de betreffende PHP installatie op de server. Die PHP module leest gewoon je .php bestand en weet niets van versie informatie. Ik wil .NET niet evangaliseren, maar .NET houdt wél rekening met versies (o.a. met een side by side cache). Bovendien compile je een ASP.NET website tot binaire MSIL instructies en weet de server om welke .NET versie het gaat. PHP gokt een eind weg wat dat betreft. Toegegeven, meestal gaat dat goed. Complete onzin


[...]

Als je mijn post beter had gelezen, dan kon je eruit opmaken dat het feit dat ASP.NET closed source is niet de reden is om ASP.NET te gebruiken.


[...]

Dan heb je IIS verkeerd ingesteld. ASP.NET 1.1 en 2.0 draaien naadloos naast elkaar, evenals allerlei release candidates en betas.

Je kan ranten wat je wilt, maar jij bent nou precies zo iemand waar je als front-ender absoluut geen steek verder mee komt.
ASP.net doet het verder voor geen meer op alle platformen behalve 2, dus jah nogal logisch dat je dan minder afhankelijk bent van changes in de omgeving, je hebt er immers minder.

Als je meer omgevingen had kun je nog net zo veel gelul hebben als bij een script taal, je kunt immers nog steeds een andere versie van een externe dll of framework hebben, want die dll bevat en leest ook alleen maar haakjes in de omgeving. Tis tenslotte geen self contained binary.

Wat ook meteen aangeeft waarom de javascript etc die uit visual studio/atlas komt ver uit mijn buurt moet blijven, ook die richten zich maar op 3 platformen, ie6, ie7, en de (oninteressante) "rest".

[Verwijderd]

killercow schreef op maandag 20 augustus 2007 @ 16:32:
Je kan ranten wat je wilt, maar jij bent nou precies zo iemand waar je als front-ender absoluut geen steek verder mee komt.

De aarde draait om de zon en PHP en ASP.NET zijn beide server-side. Wat een front-ender hiermee te maken heeft is voor mij een raadsel. Of PHP of ASP.NET over het algemeen "beter" is voor front-enders staat geheel los van wat ik hier post.

killercow schreef op maandag 20 augustus 2007 @ 16:32:
ASP.net doet het verder voor geen meer op alle platformen behalve 2, dus jah nogal logisch dat je dan minder afhankelijk bent van changes in de omgeving, je hebt er immers minder.

Zeker, ik zie dat juist als een voordeel, jij niet?
Je hoeft mijn mening ook niet te delen.

killercow schreef op maandag 20 augustus 2007 @ 16:32:
Als je meer omgevingen had kun je nog net zo veel gelul hebben als bij een script taal, je kunt immers nog steeds een andere versie van een externe dll of framework hebben, want die dll bevat en leest ook alleen maar haakjes in de omgeving. Tis tenslotte geen self contained binary.

Volgens mij zei ik net iets over een side by side cache. Je kunt op een .NET systeem oneindig veel versies van dezelfde DLL hebben. Je ASP.NET website pakt de goede. Is die versie er niet, dan doet je site het niet. Duidelijkheid heet dat. Dat heb ik liever dan in het wilde weg gokkende PHP interpreter. Maargoed, verschil van voorkeur misschien.

[killercow]

Verwijderd schreef op maandag 20 augustus 2007 @ 16:44:
[...]

De aarde draait om de zon en PHP en ASP.NET zijn beide server-side. Wat een front-ender hiermee te maken heeft is voor mij een raadsel. Of PHP of ASP.NET over het algemeen "beter" is voor front-enders staat geheel los van wat ik hier post.

Idd, het heeft er weinig mee te maken, behalve dat er hier iemand asp.net komt verkondigen als oplossing voor front-end werk. (javascript is zeer nuttig, maar idd als je geen clue hebt van javascript is het lastig en eng, dan kun je het beter server-side oplossen, of dat nou de meest klant vriendelijke oplossing is valt te bezien, maar ok)

Zeker, ik zie dat juist als een voordeel, jij niet?
Je hoeft mijn mening ook niet te delen.

Nee, ik het ondervonden dat de afhankelijk van een bepaald platform, en dan in het bijzonder een gesloten, proprietair platform niet alleen nadelig maar zelfs gevaarlijk kan zijn. Dat is trouwens geen mening, dat is een constatering.

Volgens mij zei ik net iets over een side by side cache. Je kunt op een .NET systeem oneindig veel versies van dezelfde DLL hebben. Je ASP.NET website pakt de goede. Is die versie er niet, dan doet je site het niet. Duidelijkheid heet dat. Dat heb ik liever dan in het wilde weg gokkende PHP interpreter. Maargoed, verschil van voorkeur misschien.

Juist, net of je bij php de versie nummers niet kunt uitlezen, en de API's elke punt release volledig veranderen. wat een onzin.

[Verwijderd]

killercow schreef op maandag 20 augustus 2007 @ 16:50:
Idd, het heeft er weinig mee te maken, behalve dat er hier iemand asp.net komt verkondigen als oplossing voor front-end werk.

Nee, ik "verkondig" hoogstens server-side als het alternatief voor client-side. Ík geloof namelijk niet in platformonafhankelijkheid. Dát is namelijk gevaarlijk aangezien dezelfde code (of het nou JavaScript of de broncode van PHP is) simpelweg niet enkel ontworpen wordt voor waar het uiteindelijk op terecht komt of kan komen. Maargoed, ook dat is een persoonlijke voorkeur.

killercow schreef op maandag 20 augustus 2007 @ 16:50:
Juist, net of je bij php de versie nummers niet kunt uitlezen, en de API's elke punt release volledig veranderen. wat een onzin.

Tuurlijk kun je versienummers uitlezen vanuit je PHP code. Maar ben jij bereid om in je code aanpassingen te maken voor specifieke PHP versies zoals men dat ook al sinds jaar en dag in JavaScript doet voor verschillende browsers? Daarmee bedoel ik met if-else interpreter veranderingen afhandelen. Voorkeuren, en mijne is duidelijkheid en zekerheid dat het altijd draait zoals je het bedoeld hebt als programmeur. Dat je beperkt bent tot server-side en Windows kan mij geen hol schelen.

Stel je host je website bij een webhoster. Voel jij je 100% gerustgesteld als jouw webhoster elke nieuwe "stable" PHP versie installeert? Ik herinner mij de goede oude DLL Hell nog. In .NET is dat dus helemaal opgelost. Nu PHP nog.

Dit begint trouwens een ASP.NET vs. PHP topic te worden en ik heb erg weinig zin om deze discussie voort te zetten. Ik wist allang dat de doorsnee tweaker liever PHP en Linux gebruikt Ik zoek geen confrontatie, ik geef alleen aan waarom ik geen scripts, zoals JavaScript om nog even on-topic te blijven, gebruik.

[ Voor 3% gewijzigd door Verwijderd op 20-08-2007 17:50 ]

[Grijze Vos]

Ik wil best op je PHP vs ASP.NET ingaan, maar dat is behoorlijk offtopic.
(misschien tijd voor nog een topic afspliting, modjes? )

Ik vind die houding van "compiled is beter" want dan heb je tenminste een binary echt een slechte insteek. Maar goed, als je daarover meer wilt horen, topicsplit of maak een nieuw topic.

[crisp]

Verwijderd schreef op maandag 20 augustus 2007 @ 17:16:
[...]

Tuurlijk kun je versienummers uitlezen vanuit je PHP code. Maar ben jij bereid om in je code aanpassingen te maken voor specifieke PHP versies zoals men dat ook al sinds jaar en dag in JavaScript doet voor verschillende browsers? Daarmee bedoel ik met if-else interpreter veranderingen afhandelen.

Als dat je kennisniveau is van javascript dan zou ik het ook bij serverside houden
De kunst van het goed gebruik van clientside scripting is juist om het op een unobtrusive manier toe te passen en op basis van object-detection (ipv browser-sniffing) gelaagd functionaliteit toe te voegen.

Daarbij wil ik graag opmerken dat javascript juist een hele solide en consistente basisondersteuning geniet onder de verschillende UA's. Enkel IE is nog een buitenbeentje mbt rammelende en incomplete DOM-ondersteuning maar over de gehele linie zijn interpretatie-verschillen al jaren geen probleem meer.

[Verwijderd]

crisp schreef op maandag 20 augustus 2007 @ 18:13:
Als dat je kennisniveau is van javascript dan zou ik het ook bij serverside houden
De kunst van het goed gebruik van clientside scripting is juist om het op een unobtrusive manier toe te passen en op basis van object-detection (ipv browser-sniffing) gelaagd functionaliteit toe te voegen.

Daarbij wil ik graag opmerken dat javascript juist een hele solide en consistente basisondersteuning geniet onder de verschillende UA's. Enkel IE is nog een buitenbeentje mbt rammelende en incomplete DOM-ondersteuning maar over de gehele linie zijn interpretatie-verschillen al jaren geen probleem meer.

Volgens mij is dit niet het topic om ons integrale kennisniveau van JavaScript te delen, maar als je dat graag wilt weten van mij, mag je dat best weten hoor.

Je hebt gelijk dat JavaScript waardevol kan zijn. Maar zoals je zelf zegt rammelt de meest gebruikte browser. Hoeveel JavaScript en CSS work-arounds zijn er wel niet? Dat is echt niet iets van vroeger. CSS kun je niet naar de server verplaatsen, JavaScript wel. Ik zie nog steeds niet in waarom men dit niet zoveel mogelijk doet.

Om nog even terug te komen op mijn "kennisniveau" van JavaScript: de redenatie van "het is een script dus ik gebruik het niet" is inderdaad kort door de bocht, maar reden genoeg voor mij om JavaScript zoveel als mogelijk te vermijden. We hebben het nog niet over XSS, nauwelijks ondersteuning voor PDA's en smartphones en blokkades door de browser uit veiligheid gehad.

[FragFrog]

Is een kwestie van smaak denk ik negerzoen. Als je een drukbelaste site hebt kan het in mijn opinie geen kwaad dingen zoveel mogelijk met javascript af te handelen, als je maar zorgt voor een goede fallback wanneer dingen niet ondersteunt worden. Zaken als formvalidatie etc kun je prima clientside laten afhandelen, scheelt je gebruiker weer een refresh en jou weer een berg moeite om alle formdata in te laten vullen vanuit je POST gegevens. Zo zijn er veel meer dingen waarvoor ik persoonlijk juist meer javascript zou willen gebruiken en de voornaamste reden waarom ik het niet doe is omdat ik me er nooit op toegelegd heb en de kennis mis. Een oude codepartner van me heeft die kennis bijvoorbeeld wel en ik sta geregeld jaloers te kijken wat hij wel niet voor gave dingen voor elkaar krijgt met wat javascript en origineel denken

[killercow]

Verwijderd schreef op maandag 20 augustus 2007 @ 18:29:
[...]


Om nog even terug te komen op mijn "kennisniveau" van JavaScript: de redenatie van "het is een script dus ik gebruik het niet" is inderdaad kort door de bocht, maar reden genoeg voor mij om JavaScript zoveel als mogelijk te vermijden. We hebben het nog niet over XSS, nauwelijks ondersteuning voor PDA's en smartphones en blokkades door de browser uit veiligheid gehad.

Waar denk je dat dit topic over gaat eigenlijk?
Juist over het feit dat er inderdaad best veel over te weten valt, en dat er best veel werk in zit. Dat jij die expertise niet hebt is geen reden om javascript af te schieten, javascript voegt mits correct toegepast een enorme verrijking toe aan de user-interface voor de gebruiker. (of heb jij google maps nog liever de old fasion way, klikje links, reload, klikje naar boven, refresh?)

Het punt van dit topic is juist dat het hele opbouwen van de client-side niet zomaar begrepen kan worden door een server-side devver, en dat het veel meer omvat dan wat een server side devver er zomaar bij kan doen.
Jij bevestigd mijn inziens de hele stelling van dit topic.

Ik hoop dat je met je instelling jezelf niet hopeloos uit de markt beargumenteerd. De markt gaat helaas voor jouw (en om goede redenen) precies de andere kant op.

(ps, de oorzaak van xss problemen ligt 99% van de tijd in de serverside code, en niet in de javascript)

[ Voor 3% gewijzigd door killercow op 20-08-2007 18:50 ]

[BikkelZ]

Verwijderd schreef op maandag 20 augustus 2007 @ 16:23:
[...]
Niet backward compatible? In de documentatie van .NET is bij elke class en method te vinden op welk platform deze wel of niet ondersteund wordt. .NET is nou eenmaal een framework op een besturingssysteem. En als dat besturingssysteem even iets niet ondersteunt, dan staat dat netjes gedocumenteerd. Ik zie je probleem niet.

Probeer PHP3 code maar eens te draaien onder PHP5. Afhankelijk van de server config geen tot weinig moeite. Idem voor 4 naar 5, al heb je daar nog wel eens wat problemen doordat verwijzingen naar classes zijn veranderd, die je in 3 natuurlijk helemaal nog niet kon gebruiken.

Ik vind het behoorlijk spijkers op laag water zoeken, de meeste mensen migreerden niet van PHP4 naar PHP5 omdat ze dan niet alleen hun code opnieuw moeten testen (dat doe jij hopelijk toch ook als je een nieuwe versie van IIS gaat draaien?) maar ook gebruik moeten gaan maken van nieuwe features om een migratie uberhaupt nut te laten hebben.

Dingen als HTTP_POST_VARS en HTTP_GET_VARS (van voor mijn tijd) en magic_quotes ellende zijn er natuurlijk wel langzaam uit aan het gaan. En dat vindt niemand erg.

Verwijderd schreef op maandag 20 augustus 2007 @ 16:23:
[...]Niet forward compatible? ASP.NET 1.1 draait moeiteloos op Windows Server 2003.

Geen idee dus wat je bedoelt.

Als je onder forward compatible verstaat dat oude meuk op nieuwe machines draait, dan bedoelde ik het omgekeerde van wat jij dacht dat ik bedoelde (verkeerde interpreter? ).

Maar genoeg platform flamewars, als er nog mensen te vinden zijn die een 20e eeuwse zo goed als statische webapplicatie weten te verkopen, ben ik blij voor ze. Voor de rest van ons: Let's pray for IE8!

[Erkens]

Verwijderd schreef op maandag 20 augustus 2007 @ 18:29:
Je hebt gelijk dat JavaScript waardevol kan zijn. Maar zoals je zelf zegt rammelt de meest gebruikte browser. Hoeveel JavaScript en CSS work-arounds zijn er wel niet? Dat is echt niet iets van vroeger. CSS kun je niet naar de server verplaatsen, JavaScript wel. Ik zie nog steeds niet in waarom men dit niet zoveel mogelijk doet.

Response time. Om voor elk wissewasje een request naar de server te doen is gewoon niet handig, zeker niet als veel dingen al op de client afgehandeld kunnen worden. Om maar even het simpele voorbeeld te geven van formulier validatie.

Work-arounds, niet echt veel nodig. Wat je doet is eventuele missende functies in IE erbij maken, dat is het mooie van javascript. Natuurlijk kom je ooit op een punt dat je een work-around nodig hebt, maar zo erg is dat opzich nog niet, echter jij kijkt vanuit jouw standpunt en wilt nooit compatible zijn met andere platformen, tja ooit kom je jezelf nog wel eens tegen

Overigens kan je CSS ook prima verschuiven naar de server: inline styles toepassen, of waarom niet meteen een font-tag gebruiken?

We hebben het nog niet over XSS, nauwelijks ondersteuning voor PDA's en smartphones en blokkades door de browser uit veiligheid gehad.

Een goede frontend developer zal ervoor zorgen dat een site ook nog werkt zonder javascript
XSS? Is niet echt een issue, althans niet alleen voor de client, het server gedeelte speelt daar ook een grote rol in. (en XSS is overigens soms ook mogelijk zonder dat je zelf javascript gebruikt in je applicatie/site)

[Verwijderd]

FragFrog, ben het helemaal met je eens. Ook die opmerking over Google Maps van killercow is terecht. Ik zei trouwens al dat voor visuele effecten JavaScript gewoon nodig is.

Ik denk dat ik in het algemeen geldt dat elke belangrijke JavaScript code iig ook server-side moet staan. Form validatie is hier een goed voorbeeld van. Voor de goede orde, ik gebruik dat zelf ook. Ik doel met mijn stellingen meer op niet-visuele effecten, dus code dat iets vitaals doet. Ik, maar dat is persoonlijk, wil daar zoveel mogelijk controle op hebben en wil zeker zijn van het executie verloop. Dat is dus server-side code op een platform waarvan je heel zeker weet hoe de executie verloopt.

killercow schreef op maandag 20 augustus 2007 @ 18:48:
Dat jij die expertise niet hebt is geen reden om javascript af te schieten, javascript voegt mits correct toegepast een enorme verrijking toe aan de user-interface voor de gebruiker.

Lees eerst mijn posts eens voordat je reageert met dat soort onzin. Volgens mij hebben visuele effecten namelijk betrekking op user-interface, en heb ik genoeg ervaring met JavaScript om te kunnen bepalen wat aan welke kant van de lijn hoort.

killercow schreef op maandag 20 augustus 2007 @ 18:48:
Jij bevestigd mijn inziens de hele stelling van dit topic.

Ik zou die stelling bevestigen als ik ontken dat client-side coding iets voor erbij is. Dat heb je mij niet horen zeggen. In mijn eerste post in dit topic schreef ik dat client-side coding een vak apart is.

killercow schreef op maandag 20 augustus 2007 @ 18:48:
Ik hoop dat je met je instelling jezelf niet hopeloos uit de markt beargumenteerd. De markt gaat helaas voor jouw (en om goede redenen) precies de andere kant op.

Ha, welke kant op zei je? Ongecontroleerde JavaScript? Zeker, we gaan naar rich clients, al dan niet in webbrowsers, maar denk maar niet dat het fundament daarvan JavaScript zal zijn, althans niet in de huidige vorm.

BikkelZ schreef op maandag 20 augustus 2007 @ 19:07:
Probeer PHP3 code maar eens te draaien onder PHP5. Afhankelijk van de server config geen tot weinig moeite. Idem voor 4 naar 5, al heb je daar nog wel eens wat problemen doordat verwijzingen naar classes zijn veranderd, die je in 3 natuurlijk helemaal nog niet kon gebruiken.

Ik doelde eigenlijk op het omgekeerde. Verder bedoelde ik vooral geen versie controle bij een include instructie.

Erkens schreef op maandag 20 augustus 2007 @ 19:07:
Work-arounds, niet echt veel nodig. Wat je doet is eventuele missende functies in IE erbij maken, dat is het mooie van javascript. Natuurlijk kom je ooit op een punt dat je een work-around nodig hebt, maar zo erg is dat opzich nog niet, echter jij kijkt vanuit jouw standpunt en wilt nooit compatible zijn met andere platformen, tja ooit kom je jezelf nog wel eens tegen

Ja ik vind dat zelf niet mooi eigenlijk. Maargoed, ik ben in zoverre compatible met andere platformen dat de websites (voor zover ik commercieel in die wereld zit) gewoon zonder warnings door die validators van W3C komen. Ik geloof in het algemeen niet in platformonafhankelijkheid voor elke vorm van instructies; dus voor mij geen Java, JavaScript, Mono, PHP, etc, voorlopig that is. Maargoed heel ander onderwerp.

Ik zie wel wat in een topic over server-side platformen voor websites. We kunnen eindeloos discussieren over wel of niet JavaScript gebruiken maar dat blijft gedeeltelijk een kwestie van voorkeuren en doel.

[funkwurm]

Een aantal mensen is er van overtuigt dat javascript niet of op een hele ander manier voort zal bestaan in de browsers van de toekomst. Ik ben het daar niet mee eens en ik zal uitleggen waarom.

Een doel wat het W3C met XHTML 2.0 en mogelijk ook HTML 5.0 voor ogen heeft is om de verschillende onderdelen (indeling c.q. (x)html, opmaak c.q. css, gedrag c.q. javascript, etc) meer en duidelijker te scheiden. Dit is omdat de user agent dan zelf kan bepalen welke onderdelen het ondersteunt en welke niet, afhankelijk van wat voor user agent het is (smartphone, pda, spreekcomputer, in de toekomst wellicht je koelkast, etc). De alternatieven die genoemd worden (flash, silverlight) zijn aantrekkelijk omdat die scheiding er niet of minder is, maar dat maakt ze uiteindelijk dus ook minder geschikt voor de doeleinden die op het hele web betrekking hebben.

Dat de situatie voor webapplicaties die binnen 1 bedrijf met 1 standaard systeem/browser installatie gebruikt worden wellicht zal veranderen zou kunnen, maar als je naar dingen als de google applications kijkt zullen die volgens mij niet snel (volledig) op flash/silverlight overstappen. "volledig" omdat voor bijvoorbeeld video al wel flash gebruikt wordt, google video zal dan ook niet heel veel doen op een spreekcomputer, maar je kunt je afvragen hoeveel blinden op internet naar video's op zoek gaan

[Erkens]

Verwijderd schreef op maandag 20 augustus 2007 @ 19:49:
Ja ik vind dat zelf niet mooi eigenlijk. Maargoed, ik ben in zoverre compatible met andere platformen dat de websites (voor zover ik commercieel in die wereld zit) gewoon zonder warnings door die validators van W3C komen.

Alleen met valideren ben je er nog niet.

Ik geloof in het algemeen niet in platformonafhankelijkheid voor elke vorm van instructies; dus voor mij geen Java, JavaScript, Mono, PHP, etc, voorlopig that is. Maargoed heel ander onderwerp.

Dat die talen platform onafhankelijkheids mogelijkheden bieden betekend niet dat je ook platform onafhankelijk moet gaan werken. Overigens wel leuk dat je Mono roept terwijl je zelf ook .NET gebruikt

Ik zie wel wat in een topic over server-side platformen voor websites. We kunnen eindeloos discussieren over wel of niet JavaScript gebruiken maar dat blijft gedeeltelijk een kwestie van voorkeuren en doel.

Dit topic is een discussie over het wel of niet gebruiken van JavaScript en de manier waarop mensen naar o.a. JavaScript kijken. Overigens zie ik ook wel wat in een apart topic over platform (on)afhankelijkheid

[funkwurm]

Verwijderd schreef op maandag 20 augustus 2007 @ 19:49:
Ik zie wel wat in een topic over server-side platformen voor websites. We kunnen eindeloos discussieren over wel of niet JavaScript gebruiken maar dat blijft gedeeltelijk een kwestie van voorkeuren en doel.

Erkens schreef op maandag 20 augustus 2007 @ 22:51:
Dit topic is een discussie over het wel of niet gebruiken van JavaScript en de manier waarop mensen naar o.a. JavaScript kijken. Overigens zie ik ook wel wat in een apart topic over platform (on)afhankelijkheid

Ik zou zeggen

[Verwijderd]

Verwijderd schreef op maandag 20 augustus 2007 @ 19:49:
Zeker, we gaan naar rich clients, al dan niet in webbrowsers, maar denk maar niet dat het fundament daarvan JavaScript zal zijn, althans niet in de huidige vorm.

Voor zover mij bekend is JavaScript toch al een jaar of zeven, acht het fundament van interactieve websites, in vrijwel exact de huidige vorm. Wat gaat daar volgens jou aan veranderen?