Prototype of Jquery ?

[Verwijderd]

Ik wil hier hier geen flame topic over een bepaald framework starten, echter de go's en de no go's proberen te bepalen.

Ik heb momenteel een basic pagina uit een groter project welke gebruik maakt van Prototype, mede omtrent het feit dat in de tijd dat dit ontwikkeld werd Prototype "het" was.

Ik vraag me sterk af wat handig is om te doen, verder met Prototype, wat me opzich wel ligt omdat het meer OOP achter is en dus lekker werkt als je ook PHP gewend bent, of overstappen en verbouwen naar jQuery.

De userbase van jQuery is groot, veel voorbeelden te vinden, maar wellicht ook een hype ? Prototype heeft als voordeel dat het niet alleen DOM based is, het is wat meer basic en gericht op JS zelf. OOP lijkt het wel een beetje naar zoals ik vermeldde en tevens is het zo dat je wat meer zaken kunt doen als je volledig controle over je systeem hebt.

jQuery heeft ook zijn voordelen, de code is wat korter en directer vaak. Opzich verschillen beide niet veel van elkaar maar toch. Over performance kan ik niet spreken... er zijn mensen die zeggen dat jQuery sneller zou zijn, of Prototype trager

Ik heb wel gemerkt dat jQuery meer up-to-date is. Dat kan komen doordat ze een framework wilde schrijven dat "beter" is dan de rest en dus een soortement van inhaalslag (moeten) maken. Ik kan hier verder niet over oordelen en wil dat ook niet doen.

Een vraag die ik wel heb is of een framework als Prototype bestaansrecht blijft houden tov jQuery. Prototype is heerlijk basic, echter de vraag is of dat de toekomst is.

[wackmaniac]

Ik ben zelf voorstander van Prototype om de reden die je zelf aandraagt; het is wat gestructureerder opgezet naar mijn idee. Ik (en het bedrijf waar ik werk) gebruik nog gewoon Prototype, ook voor nieuwe projecten. Er wordt nog steeds aan ontwikkeld, dus dat hypen zal wel meevallen.

Verder maakt het helemaal niets uit; oplossingen voor JQuery kan je 99% van de tijd ook voor Prototype vinden en andersom. Als je nu alles al in Prototype hebt zou ik dat lekker blijven gebruiken als je graag JQuery wilt moet je een paar uurtjes spenderen aan converteren, maar die twee maken elkaar niet zoveel. Is vooral een kwestie van smaak.

[ Voor 14% gewijzigd door wackmaniac op 05-09-2011 09:33 ]

[MrOizo2005]

Het is inderdaad een kwestie van smaak. maar de overstap die ik heb gedaan van Prototype naar jQuery was omdat jQuery vroeger sneller was. Dit maakt met de huidige versies niet meer uit. Die zijn beide net zo snel.

Misschien een goede toevoeging in dit topic:
http://mootools.net/slickspeed/

[Verwijderd]

Fijn om te weten dat ik gewoon verder kan gaan met Prototype, ik vind de structuur echt lekkerder, ok kan soms iets kleiner maar is wel degelijk begrijpelijk! Je kan met Prototype wel iets meer met positioning en dergelijke dus CSS based zou het handiger zijn.

jQuery kan wel weer omgaan met noConflict() om Prototype code te runnen ? Ik moet me hier even over inlezen.

jQuery zou wel minder conflicten hebben, is dit nog steeds het "probleem" met Prototype ? De API van jQuery schijnt wel een draak ding te zijn...

Bedankt voor die link! Gaaf ding.

[ Voor 19% gewijzigd door Verwijderd op 05-09-2011 09:39 ]

[Bosmonster]

jQuery is vandaag de dag de de facto standaard. Waarschijnlijk door de extreem simpele en overzichtelijke API en daardoor de zeer lage drempel.

Ook is het ontwikkelen in jQuery voor eenvoudige website-toepassingen (en dat is verreweg het leeuwendeel) zeer snel en de library ook erg light weight. Ander voordeel is dat jQuery, in tegenstelling tot Prototype, je global space niet vervuilt. Waar Prototype honderden globale variabelen aanmaakt en bestaande objecten aanpast, heb je met jQuery dus veel minder kans op conflicten, wat wederom de drempel verlaagt.

Daarnaast is de ontwikkeling van jQuery veel actiever en sneller, en de userbase vele malen groter. De facto standaard dus.

Je hebt inderdaad de wat oudere alternatieven van Prototype, Mootools, etc, maar gezien het afnemende marktaandeel is dat meestal een keuze om goed over na te denken. Al is het maar voor (toekomstige) support.

Sommigen geven de voorkeur aan de OO-structuur van bovenstaande libraries, maar persoonlijk vind ik dat voor websites, waar het praktisch alleen gaat om losse componentjes niet nodig. Misschien als je complexere (interne) applicaties ontwikkelt, maar ook dan heb je OO/MVC-oplossingen voor jQuery, die samen nog steeds lichter zijn en minder impact hebben dan een losse Prototype bijvoorbeeld.

[ Voor 20% gewijzigd door Bosmonster op 05-09-2011 09:51 ]

[Verwijderd]

Ik denk zelf dat je teveel uit gata van "makkelijk en snel ontwikkelen".

Dat is de trend vandaag de dag echter betekent het niet dat het product er ook zo goed van wordt.

Het is ook een kwestie van smaak en jouw smaak is dus jQuery. Ik heb overigens net even die test gedraaid en Prototype is echt sneller en dus lichter dan jQuery... scheelt 10ms op 27ms voor jQeury... dus ja...

[Bosmonster]

Makkelijk en snel ontwikkelen past ook helemaal binnen de Agile development technieken vandaag de dag. Daarnaast is tijd, geld. Ik heb nooit de tijd of de mogelijkheid een complete OO-structuur op te zetten voor een paar website-plugins. Zeker niet in een scrum-traject. Daarnaast gaat het bijna altijd om plugins van letterlijk een paar regels. Prototype/Mootools zorgen hierbij voor mij voor veel te veel overhead, zowel in code als in dev-tijd.

Het resultaat van het product is hier in z'n geheel niet van afhankelijk natuurlijk. Het gaat er juist om dat je makkelijk en snel goede code kunt schrijven. Makkelijk en snel bagger schrijven kun je met ieder framework

Verder een groot nadeel van Prototype specifiek: De community is praktisch dood. De laatste versie is bijna een jaar oud (nog van voor de release van IE9 bijvoorbeeld), wat een eeuwigheid is in deze context. Hier kan ik in een professionele en commerciële omgeving simpelweg geen voorkeur aan geven.

Mootools is dan nog een enigszins serieuze kandidaat concurrent.

Overigens denk ik dat je bij je "performance test" maar even scriptaculous hebt weggelaten?

[ Voor 56% gewijzigd door Bosmonster op 05-09-2011 10:07 ]

[Acid_Burn]

Verwijderd schreef op maandag 05 september 2011 @ 09:55:
Ik denk zelf dat je teveel uit gata van "makkelijk en snel ontwikkelen".

Dat is de trend vandaag de dag echter betekent het niet dat het product er ook zo goed van wordt.

Het is ook een kwestie van smaak en jouw smaak is dus jQuery. Ik heb overigens net even die test gedraaid en Prototype is echt sneller en dus lichter dan jQuery... scheelt 10ms op 27ms voor jQeury... dus ja...

Hier 9ms (jQuery) vs 7ms(Prototype). Daarbij heeft hij bij het gros van de test hetzelfde resultaat met een enkele hier en daar die 1ms scheelt.

[Styxxy]

MrOizo2005 schreef op maandag 05 september 2011 @ 09:33:
Misschien een goede toevoeging in dit topic:
http://mootools.net/slickspeed/

Ik vind de test nu ook niet geheel correct. Er wordt gebruik gemaakt van een erg oude jQuery versie tegenover een zeer recente Mootools versie.

Overigens een leuke website: http://jqueryvsmootools.com/ (wel al tijdje oud).

[Verwijderd]

Als ik zoek naar jQuery voorbeeld van bijvoorbeeld userinterfaces of private message systemen, iets wat veel gebruikt wordt en waar veel vraag naar is, dan kan ik beide niet goed vinden.

Het beeld dat ik hiervan krijg is dat er losse flodders worden gebouwd omdat het zo "makkelijk" is en je eigenlijk niet echt een goed beeld krijgt van daadwerkelijke functies.

Ik ben bijvoorbeeld gaan zoeken of er voorbeelden zijn voor een PM-systeem waarbij een dynamische inbox beschikbaar is. Er wordt veel over gesproken maar voorbeeld zijn er niet vreselijk veel en dan vind ik vreemd.

Hetzelfde als userinterfaces waarbij een simpel member systeem gebruikt wordt met PHP en MySQL, opzich geen rocket science, veel vragen over maar geen concrete voorbeelden.

Er zijn legio kalenders te vinden die jQuery based zijn... voor dat soort dingen wordt het natuurlijk ook gebruikt

[iH8]

Ik ben helemaal voor een weloverwogen keuze van framework, daarom denk ik dat dit potentieel een hele mooie topic worden kan, beetje jammer dat je alleen maar begint over Jquery en Prototype. Leuke stats over js-framework penetratie, kun je meteen zien welke spelers er nog meer mee doen:

http://w3techs.com/technologies/market/javascript_library/10

[Bosmonster]

Verwijderd schreef op maandag 05 september 2011 @ 12:31:

Ik ben bijvoorbeeld gaan zoeken of er voorbeelden zijn voor een PM-systeem waarbij een dynamische inbox beschikbaar is. Er wordt veel over gesproken maar voorbeeld zijn er niet vreselijk veel en dan vind ik vreemd.

Misschien omdat dit soort dingen niet kant-en-klaar klaarliggen, maar eenvoudig zelf zijn te ontwikkelen?

Plugins zijn er bizar veel voor jQuery, maar maak er maar heel weinig gebruik van. Hooguit modules die je echt werk uit handen nemen zoals history of throttling.

[Verwijderd]

iH8 schreef op maandag 05 september 2011 @ 13:00:
Ik ben helemaal voor een weloverwogen keuze van framework, daarom denk ik dat dit potentieel een hele mooie topic worden kan, beetje jammer dat je alleen maar begint over Jquery en Prototype. Leuke stats over js-framework penetratie, kun je meteen zien welke spelers er nog meer mee doen:

http://w3techs.com/technologies/market/javascript_library/10

Je ziet dat Prototype en jQuery eigenlijk het beste uit dat overzicht komen ?

[iH8]

Verwijderd schreef op maandag 05 september 2011 @ 13:08:
[...]


Je ziet dat Prototype en jQuery eigenlijk het beste uit dat overzicht komen ?

Nee, ik zie dat Dojo het beste uit dat overzicht komt hehe

[Bosmonster]

Dojo is ook een prima alternatief, waar actief aan ontwikkeld wordt en een prima userbase voor is. Grote voordeel is dat het niet 1 library is, maar dat het bestaat uit losse dynamisch te laden componenten. En dat het aantal standaard componenten erg uitgebreid is.

Iets wat ik ook een nadeel vind van jQuery. jQuery UI is niet zo denderend, maar die hoef je niet te gebruiken gelukkig.

[ Voor 30% gewijzigd door Bosmonster op 05-09-2011 13:20 ]

[Verwijderd]

iH8 schreef op maandag 05 september 2011 @ 13:14:
[...]


Nee, ik zie dat Dojo het beste uit dat overzicht komt hehe

Ja voor high traffic sites, echter zijn die er niet vreselijk veel... of weinig die het gebruiken

Wat is er mis met de jQuery UI ?

[ Voor 5% gewijzigd door Verwijderd op 05-09-2011 13:33 ]

[Bosmonster]

Verwijderd schreef op maandag 05 september 2011 @ 13:32:
[...]

Wat is er mis met de jQuery UI ?

Rommelige, inconsistente API en buggy.

Ook incompleet en er gebeurt niet zo heel veel meer mee heb ik het idee.

Maar voor volledige UI's zijn er ook betere libraries, zoals Dojo.

[Verwijderd]

Bosmonster schreef op maandag 05 september 2011 @ 14:41:
[...]


Rommelige, inconsistente API en buggy.

Ook incompleet en er gebeurt niet zo heel veel meer mee heb ik het idee.

Maar voor volledige UI's zijn er ook betere libraries, zoals Dojo.

Tja... waarom cross frameworks gebruiken... dat snap ik nu weer niet!

[Bosmonster]

Nee, niet cross framework, een framework pakken dat bedoeld is voor wat je gaat ontwikkelen.

Standaard websites met wat interactie -> jQuery
Complete GUI's / WebApps -> Dojo (of EXT, DHTMLX, etc, heb ik niet zoveel ervaring mee)

[Verwijderd]

Bosmonster schreef op maandag 05 september 2011 @ 16:03:
Nee, niet cross framework, een framework pakken dat bedoeld is voor wat je gaat ontwikkelen.

Standaard websites met wat interactie -> jQuery
Complete GUI's / WebApps -> Dojo (of EXT, DHTMLX, etc, heb ik niet zoveel ervaring mee)

Tja... DHTMLX is een commercieel bedrijf dus dat valt direct al af. En waarom wel een Dojo waar ik echt te weinig over vind....

Ik zie weinig onderbouwing van je dus zie ik het meer als een persoonlijke keus

[Bosmonster]

Verwijderd schreef op maandag 05 september 2011 @ 16:10:
[...]

Tja... DHTMLX is een commercieel bedrijf dus dat valt direct al af. En waarom wel een Dojo waar ik echt te weinig over vind....

Ik zie weinig onderbouwing van je dus zie ik het meer als een persoonlijke keus

Ik kan er weinig aan doen dat jij een framework als Dojo niet kent

Er is een duidelijke scheiding tussen losse libraries zoals Prototype/Scriptaculous, Mootools, jQuery, etc en de complete GUI-frameworks zoals Dojo, ExtJS, DHTMLX, etc.

Dojo valt er nog ietwat tussenin door de zeer modulaire opbouw, maar ook daar ligt de focus veel meer op de technischere oplossingen en backend koppelingen.

Dat kun je ook wel met een berg plugins bereiken in de libraries uiteindelijk (alles kan), maar dan ben je niet handig bezig (bijvoorbeeld dit of dit). Dat is idd mijn mening...

[ Voor 7% gewijzigd door Bosmonster op 05-09-2011 16:42 ]

[crisp]

Toevallig is deze discussie hier intern onlangs ook langsgekomen. Een genoemd argument om een JS framework te gaan gebruiken was dat 'het classloze object-model van Javascript vereist ook een paradigma-shift die lastig is voor PHP-developers'. Ik heb dat in ieder geval als argument genomen om dan in ieder geval niet voor jQuery te kiezen

Uiteindelijk is de conclusie geweest dat we blijven bij onze eigen library welke eigenlijk een samenraapsel is van 'best practices' uit verschillende libraries en eigen werk. Voor de toekomst zie ik meer in mini-frameworks in de vorm van 'snippets' dan in monolitische frameworks zoals jQuery die een eigen idioom opleggen. De mogelijkheden van (core) javascript zelf raken steeds uitgebreider waardoor de noodzaak van een library of framework ook afneemt en browser-compatibility issues makkelijker met shivs of shims kunnen worden opgelost.

Het grootste voordeel van een dergelijke approach is imho dat je een echte programmeertaal leert, en niet een halfbakken abstractie.

jQuery is leuk voor simpele dingen, maar 'terse' syntax en 'css-like'-selectors zijn in een iets complexere omgeving eerder een nadeel dan een voordeel: het is lastiger debuggen, en ingewikkelde selectors leggen een zeer sterke dependency met je markup. Persoonlijk heb ik altijd genoeg gehad aan id en class-selectors.

Verder vind ik jQuery's API teveel een 'Pandora's box' waarbij het type output bepaald wordt door de input: $(foo) kan van alles zijn, terwijl document.getElementById(foo) of document.createElement(foo) veel explicieter (en dus minder bug-gevoelig) zijn (en ja, dat is qua syntax veel langer, maar dat lost HTTP compressie prima op ).

Scope is ook nog een probleem in jQuery; 'this' is niet altijd wat je verwacht dat het zou zijn (en ja, je hebt de proxy-method, maar da's een workaround).

Verder nodigt het jQuery-idioom veel meer uit tot inefficiënte code (nodeloos herhalen van DOM-queries binnen loops bijvoorbeeld).

Als je een library zoekt die dicht tegen javascript zelf aanleunt dan zou ik zelf prototype aanbevelen (hoewel dat weer meer Ruby prentendeert te zijn), en anders gewoon eens te kijken naar beschikbare mini-frameworks en shims/shivs waarmee je je eigen codebase klein kan houden en gewoon lekker kan programmeren in javascript

[Bosmonster]

crisp schreef op dinsdag 06 september 2011 @ 00:58:

jQuery is leuk voor simpele dingen, maar 'terse' syntax en 'css-like'-selectors zijn in een iets complexere omgeving eerder een nadeel dan een voordeel: het is lastiger debuggen, en ingewikkelde selectors leggen een zeer sterke dependency met je markup. Persoonlijk heb ik altijd genoeg gehad aan id en class-selectors.

Daar ben ik het helemaal mee eens. Als je de tijd hebt, bijvoorbeeld bij een complexer in-huis product zoals T.NET/GoT, waar micro-optimalisatie hoog in het vaandel staat, loont het zeker om verder te kijken dan de standaard libraries. Wat ik eerder al zei dus, er zijn meer wegen naar Rome en niet ieder project of iedere situatie vraagt om dezelfde oplossing.

Maar in een omgeving waar je met verschillende frontenders werkt, die niet altijd even technisch onderlegd zijn, en waar de projecten in rap tempo worden afgewerkt, loont het wel om een standaard aan te houden waar iedereen bekend mee is. Die leesbare syntax en css-selectors zijn dan ineens een groot voordeel bijvoorbeeld. Standaardisatie en ontwikkelsnelheid zijn dan belangrijker.

De uren die jullie in dit product kunnen stoppen (of die je moet stoppen in het opleiden van nieuwe frontenders) krijg je nooit verkocht natuurlijk

offtopic: En toch krijg je soms klanten langs die denken dat je een site als T.NET kunt bouwen voor een ton ofzo

[ Voor 15% gewijzigd door Bosmonster op 06-09-2011 07:45 ]

[Verwijderd]

Crisp, ik dank je voor je bijdrage! Ik denk er hetzelfde over, ik heb dit zelfde met PHP frameworks gehad. Ik heb uiteindelijk mijn eigen framework ontwikkeld dat prima werkt mede omdat je zelf de affiniteit van het framework bepaald en dus ook weet waarom je functies gebruikt op een dergelijke manier, je kunt dit dus inderdaad lekker basic houden als je wil.

Zoals je zelf aangeeft ligt Prototype het dichtst tegen javascript aan en is hierdoor begrijpelijk en tevens overzichtelijk.

Ik ben het met je eens dat frameworks als jQuery populair worden doordat je snel even iets kan maken waarbij je op een gegeven moment niet meer weet waarom je iets doet of gebruikt.

Persoonlijk denk ik dat we inderdaad de kant op gaan zoals je zegt, kleine mini frameworks, maar wel met het beste van waar ze voor dienen qua code.

Neemt niet weg dat je met jQuery inderdaad even snel iets makkelijks in elkaar zet.....

[ Voor 7% gewijzigd door Verwijderd op 06-09-2011 08:44 ]

[Verwijderd]

jQuery is fantastisch als je het gebruikt waar het voor bedoeld is: het makkelijk maken van dingen die in plain JS moeilijk zijn, langdradig zijn of crossbrowser problemen hebben. Voor mij zijn dit voornamelijk Ajax, DOM manipulatie en event handling.

jQuery maakt je geen betere programmeur, natuurlijk, en het heeft zeker features die uitnodigen tot minder leesbare/onderhoudbare code: chaining, multi-purpose methods, etc. Ook zijn er features die bijna niemand kent en daardoor enigszins magisch overkomen als je het voor het eerst ziet zoals deferred objects.

Toch zeg ik dat jQuery een uitstekende keuze is als je een library zoekt die je het front-end leven makkelijker moet maken. Je moet alleen wel goed opletten welke features je wel en niet gebruikt.

[Bosmonster]

Verwijderd schreef op dinsdag 06 september 2011 @ 09:58:
jQuery is fantastisch als je het gebruikt waar het voor bedoeld is: het makkelijk maken van dingen die in plain JS moeilijk zijn, langdradig zijn of crossbrowser problemen hebben. Voor mij zijn dit voornamelijk Ajax, DOM manipulatie en event handling.

En dit is 99% van wat ik dagelijks doe met JS

jQuery maakt je geen betere programmeur, natuurlijk, en het heeft zeker features die uitnodigen tot minder leesbare/onderhoudbare code: chaining, multi-purpose methods, etc. Ook zijn er features die bijna niemand kent en daardoor enigszins magisch overkomen als je het voor het eerst ziet zoals deferred objects.

Toch zeg ik dat jQuery een uitstekende keuze is als je een library zoekt die je het front-end leven makkelijker moet maken. Je moet alleen wel goed opletten welke features je wel en niet gebruikt.

Geen enkele library maakt je een betere developer natuurlijk. Je kunt overal bagger in schrijven. Bij jQuery heeft de filosofie van een kleinschalige API en korte coding style wel gevolgen inderdaad, waar je mee om moet kunnen gaan.

Maar wat bedoel je met wat je moet opletten met wat je wel en niet gebruikt? Als deferred objects precies is wat je nodig hebt dan zou ik niet weten waarom je zoiets niet zou kunnen gebruiken bijvoorbeeld.

[ Voor 5% gewijzigd door Bosmonster op 06-09-2011 10:15 ]

[MueR]

Bosmonster schreef op dinsdag 06 september 2011 @ 07:35:
Maar in een omgeving waar je met verschillende frontenders werkt, die niet altijd even technisch onderlegd zijn, en waar de projecten in rap tempo worden afgewerkt, loont het wel om een standaard aan te houden waar iedereen bekend mee is. Die leesbare syntax en css-selectors zijn dan ineens een groot voordeel bijvoorbeeld. Standaardisatie en ontwikkelsnelheid zijn dan belangrijker.

Helemaal mee eens. Of het nu jQuery, Mootools of een ander framework is, de ontwikkelsnelheid is voor de meeste mensen het belangrijkste. Daarbij is voor veel internetbureaus het ook niet realistisch om een eigen (mini-)framework te ontwikkelen en onderhouden. Daar gaat gewoon te veel tijd in zitten.

offtopic: En toch krijg je soms klanten langs die denken dat je een site als T.NET kunt bouwen voor een ton ofzo

Een ton is dan nog enigsinds realistisch, mits je genoegen zou nemen met wat minder luxe. De mensen die voor 10k de nieuwe youtube of facebook willen daarentegen...

[Juup]

Het grootste minpunt van jQuery vind ik nog altijd de grootte.
Waarom maakt niemand een jQuery Light van max 2kB minified+compressed waarin alleen

code:

$().each()

en consorten en

code:

$().ajax()

zitten?
En waarbij querySelectorAll gebruikt wordt en alleen als die niet bestaat Sizzle wordt geladen?

[ Voor 18% gewijzigd door Juup op 06-09-2011 11:10 ]

[Bosmonster]

Waarom vindt je grootte een probleem? jQuery is nog een van de kleinste libraries. Alleen Dojo komt met z'n modulaire opzet potentieel lager uit.

Het processen van de library is een veel grotere overhead dan het downloaden van 30K gzip'ed, maar dat is dan weer iets waar je in de praktijk nauwelijks last van hebt. De oudere browsers hebben Sizzle e.d. nodig, terwijl de nieuwere browsers zo snel zijn met JS dat het weer praktisch niet merkbaar is.

Uiteindelijk is het waarschijnlijk zelfs nog sneller om alles in 1 library te packen in dit geval, dan weer losse requests te gaan doen voor losse mini-componentjes, waar je script dus weer op moet wachten voor die iets kan gaan doen...

[ Voor 50% gewijzigd door Bosmonster op 06-09-2011 11:21 ]

[crisp]

jQuery is qua codesize toch wel groter dan bijvoorbeeld mootools of prototype:

library: source / minified / minified + gzip

prototype 1.7: 163.313 / 92.130 / 28.665
mootools 1.3.2: 146.186 / 88.540 / 28.382
jQuery 1.6.2: 236.202 / 91.556 / 32.099

[Bosmonster]

Ik zie praktisch geen verschil eerlijk gezegd, behalve dat de source 100K meer documentatie bevat

Verder moet je ook even kijken naar de functionaliteit natuurlijk. Prototype wordt niet voor niks bijna altijd met scriptaculous gebruikt bijvoorbeeld.

[McVirusS]

En als je zorgen maakt over bestandsgrootte kan je altijd nog jQuery laden van Google.com, zodat hij gecached wordt over meerdere sites heen .

[Verwijderd]

Hoe wordt hier overigens gedacht over Yahoo Yui ? Bruikbaar of lekker achterwege laten ?

[Verwijderd]

Ik ben me momenteel ook zeer aan het inlezen over ExtJS. Ik heb me hier al eens eerder in verdiept en de mogelijkheden zijn echt legio!

Wat me alleen opvalt is dat je zoveel van de magic weg geeft omdat het eigenlijk allemaal client based is. Dat valt me zwaar tegen van dat JS verhaal... erg makkelijk te jatten voor een ander.

[Bigs]

ExtJS is nogal iets anders dan Prototype of jQuery.. ze hebben denk ik nogal verschillende doelen. YUI zit er een beetje tussenin.

[Verwijderd]

Bigs schreef op woensdag 07 september 2011 @ 08:52:
ExtJS is nogal iets anders dan Prototype of jQuery.. ze hebben denk ik nogal verschillende doelen. YUI zit er een beetje tussenin.

Wat je zegt, wordt me zeker duidelijk. Maar je zal ergens een keus moeten maken, en ExtJS is toch wel erg fijn. YUI heeft ook zijn voordelen maar is niet mijn ding heb ik al gemerkt.

Het enige wat ik dus met ExtJS heb is dat je er erg mooie dingen mee kunt maken maar je verhaal wel even op straat legt....

[Priet]

Bigs schreef op woensdag 07 september 2011 @ 08:52:
ExtJS is nogal iets anders dan Prototype of jQuery.. ze hebben denk ik nogal verschillende doelen. YUI zit er een beetje tussenin.

Klopt. Maar je kunt van ExtJS ook veel gebruiken zonder iets met de GUI elementen te doen.

Ik gebruik jQuery en ExtJS door elkaar. jQuery voor eenvoudige DOM manipulatie en ExtJS voor zaken als Ext.data.Store, Ext.view.View en Ext.data.Model. Zaken als popup dialogs heb ik dan als plugin voor jQuery gemaakt.

[Bosmonster]

Als je er echt iets modulairs tussenin zoekt, dan is Dojo wel echt de moeite waard om eens naar te kijken dus.

[R4gnax]

Verwijderd schreef op woensdag 07 september 2011 @ 09:04:
Wat je zegt, wordt me zeker duidelijk. Maar je zal ergens een keus moeten maken, en ExtJS is toch wel erg fijn.

ExtJS is een erg groot en compleet pakket. Jammer is alleen dat er een aantal fundamentele zaken dan weer net niet goed geregeld zijn. Hierdoor is het, wanneer je complexere zaken gaat implementeren, toch al vrij snel nodig om diep in de 'guts' van het framework te duiken en daar code tegenaan te gaan schrijven.

Wil je bijv. een AjaxProxy voor een Store hebben die zijn request parameters mbv JSON verstuurd i.p.v. gewone POST parameters? Dan mag je een eigen Proxy gaan schrijven. Dit is anders nl. niet 100% werkend te krijgen.

Wees daar wel op voorbereid!

[Verwijderd]

Het probleem met dat JS verhaal is dat je je code echt beschikbaar stelt voor iedereen die hetzelfde wil.

PHP, een hoek waar ik uit kom qua proggen, is lekker serverside en dus veilig voor hoe je je data presenteert.

De data die je presenteert kun je natuurlijk ook mij JS afschermen echter kan de manier hoe je het presenteert nog wel eens fanciër zijn dan de data opzich.... als dat een POS is, je JS scripting is het vervelend als een ander dit even afpakt.

Dat is echt een dilemma voor vandaag!

[NetForce1]

Verwijderd schreef op woensdag 07 september 2011 @ 15:55:
Het probleem met dat JS verhaal is dat je je code echt beschikbaar stelt voor iedereen die hetzelfde wil.

PHP, een hoek waar ik uit kom qua proggen, is lekker serverside en dus veilig voor hoe je je data presenteert.

De data die je presenteert kun je natuurlijk ook mij JS afschermen echter kan de manier hoe je het presenteert nog wel eens fanciër zijn dan de data opzich.... als dat een POS is, je JS scripting is het vervelend als een ander dit even afpakt.

Dat is echt een dilemma voor vandaag!

Dan trek je het toch lekker door een obfuscator heen.

[Verwijderd]

NetForce1 schreef op woensdag 07 september 2011 @ 16:27:
[...]

Dan trek je het toch lekker door een obfuscator heen.

Ja ik heb al wat kleine leads qua info gevonden, maar zoals alles is dat ook te decoden... maar nu even uitzoeken hoe makkelijk.

Je wil gewoon niet je bouwtekening op straat hebben in any way! lastig.

[McVirusS]

JS is niet onveiliger dan PHP; ze dienen compleet ander doel. Je moet gewoon zorgen dat je backend nooit meer data teruggeeft dan dat die gebruiker mag zien.

JS is slechts een manier om dingen wat netter te presenteren/betere interactie voor elkaar te krijgen. Snap niet wat dit te maken heeft met veiligheid van data.

Daarnaast heb je altijd nog een backend nodig dus hoe vervelend is het dat frontend code te bekijken is?

[BtM909]

Bosmonster schreef op maandag 05 september 2011 @ 09:58:
Mootools is dan nog een enigszins serieuze kandidaat concurrent.

Ik weet niet precies hoe, wat en waarom, maar het hielp de populariteit natuurlijk ook doordat een framework als .NET het standaard erbij heeft

Mootools is wel mijn favoriet wat JS-library betreft

En in lijn van crisp z'n verhaal is een tool als Ender wel wat

[Verwijderd]

McVirusS schreef op woensdag 07 september 2011 @ 16:41:
JS is niet onveiliger dan PHP; ze dienen compleet ander doel. Je moet gewoon zorgen dat je backend nooit meer data teruggeeft dan dat die gebruiker mag zien.

JS is slechts een manier om dingen wat netter te presenteren/betere interactie voor elkaar te krijgen. Snap niet wat dit te maken heeft met veiligheid van data.

Daarnaast heb je altijd nog een backend nodig dus hoe vervelend is het dat frontend code te bekijken is?

Duidelijk maar je kan aan de frontend kant altijd zien hoe je fancy verhaal is opegebouwd, bijvoorbeeld de igoogle variant is een goed voorbeeld.

Je kant natuurlijk een obfuscator toepassen, maar dit zou beter zijn als je dit realtime kunt doen... Tweakers gebruikt het volgens mij ook in de source.

[Ram0n]

Verwijderd schreef op woensdag 07 september 2011 @ 16:47:
[...]


Duidelijk maar je kan aan de frontend kant altijd zien hoe je fancy verhaal is opegebouwd, bijvoorbeeld de igoogle variant is een goed voorbeeld.

Je kant natuurlijk een obfuscator toepassen, maar dit zou beter zijn als je dit realtime kunt doen... Tweakers gebruikt het volgens mij ook in de source.

Doorgaans wil je het ook door een minifier halen, dus zodra je daar een proces voor hebt is het toepassen van een obfuscator ook geen probleem meer. Bovendien ben ik het eens met de heren enkele posts terug; hoeveel gevaarlijke informatie zal erin staan?

[Verwijderd]

Ram0n schreef op woensdag 07 september 2011 @ 16:55:
[...]

Doorgaans wil je het ook door een minifier halen, dus zodra je daar een proces voor hebt is het toepassen van een obfuscator ook geen probleem meer. Bovendien ben ik het eens met de heren enkele posts terug; hoeveel gevaarlijke informatie zal erin staan?

Het gaat niet zozeer om gevaarlijke data. Het gaat meer om het feit dat je de gaten wil leveren, niet eens de boren en vooral de manier niet hoe boren werken.

Laat ik het zo zeggen. Met PHP krijg je gewoon een bron te zien wat kleine zaken met JS gedaan kunnen worden. Verder kun je alles eigenlijk vanaf achter de schermen regelen. Dat is icm met JS wat lastiger, je "ziet" teveel van hoe zaken afgehandeld wordt richting je backend.

[Ram0n]

Ik begrijp je punt, maar in de praktijk zal dit niet zo snel tot problemen leiden. Ja, je legt meer bloot, maar nog altijd niets of weinig van de echte achtergrond van je website; dat blijft serverside. En wat is er nu precies mis met obfuscators? Die zijn prima toepasbaar in de meeste processen.

[Styxxy]

Ram0n schreef op woensdag 07 september 2011 @ 17:25:
En wat is er nu precies mis met obfuscators? Die zijn prima toepasbaar in de meeste processen.

Je moet gewoon de afweging maken: hoeveel tijd wil je in het "verbergen" steken. Uiteindelijk zal altijd het geheel begrepen worden, hoeveel moeite je er ook in steekt om de JavaScript te obfuscaten.

[Ram0n]

True, maar zoals ik al aangaf; doorgaans pas je ook al een minifier toe, en een obfuscator daartussen is dan ook niet veel extra werk. Maar goed, dit gaat een beetje te ver af van het onderwerp

[crisp]

Verwijderd schreef op woensdag 07 september 2011 @ 16:47:

Je kant natuurlijk een obfuscator toepassen, maar dit zou beter zijn als je dit realtime kunt doen... Tweakers gebruikt het volgens mij ook in de source.

Wij minifyen alleen bij deployment.

Verder is de angst voor code die gejat kan worden overigens meestal ongegrond, of je moet wel iets heel bijzonders gemaakt hebben. En zelfs dan nog heb je copyright op je eigen code en kan je de 'jatter' dus gewoon gerechtelijk aanpakken.

[Bosmonster]

Vergeet ook niet dat een clientside obfuscator een flinke aanslag is op de performance.

Uiteindelijk maakt het ook niks uit. Je gebruikt JS alleen voor je presentatielaag. Dat is niet anders dan dat je html, css en images openbaar staan. Dat ga je ook niet allemaal lopen obfuscaten

[ Voor 53% gewijzigd door Bosmonster op 07-09-2011 22:44 ]

[Kajel]

Ik begrijp de drang niet zo om de innerworkings van je JS te "verbergen" voor anderen.
Wat mij betreft zijn er 2 redenen waarom je potentieel code wil verbergen van je applicatie (en dat geldt niet alleen voor JS, maar voor alle sourcecode):
1. Je wil de veiligheid van je applicatie waarborgen en de integriteit van de data bewaken
2. Je bent bang voor jatten

In het geval van JS vervalt 1 - mits je applicatie goed in elkaar zit - in de praktijk, want JS is er gewoon voor de presentatie/interactie.
In geval van 2: Zoals crisp al zei, heb je gewoon copyright op je code, dus je kunt in het ergste geval nog altijd iemand gerechtelijk aanpakken als jouw code gekopieerd wordt.
Maar hoevaak komt het nou voor dat hetgeen jij met JS doet zo ontzettend baanbrekend is dat iemand het nergens anders kan vinden en dus met goede reden wil jatten? Om T.net maar eens als voorbeeld te gebruiken: Daar gebeuren geen baanbrekende dingen in het frontend. Het is gewoon your run-of-the-mill nieuwssite/community/advertentiesite. Hier gebeurt qua JS interacties niks waar de frontend community wakker van zal liggen. En dat geldt voor 99% van de sites.