ugrás a tartalomhoz

Magyar fejlesztésű Javascript MVC

Steve31 · 2013. Júl. 15. (H), 14.36
Sziasztok!

Kinek van kedve egy teljesen új Javascript MVC fejlesztésébe becsatlakozni ? Ez természetesen magyar fejlesztés lesz és nyílt forrású. A kiinduló részletek már ki vannak dolgozva.
Egyenlőre várok választ, hogy ki akarna becsatlakozni, minimum 1 hét a várakozási idő, utána bővebb részleteket írok.

Üdv mindenkinek!
‹ Segítség!! Háttér ablak létrehozás Segítség!! főmenü hover háttérszín, almenü kibontásakor is megmaradjon ›
 ■
1

Részletek

Hidvégi Gábor · 2013. Júl. 15. (H), 15.25
Azért egy kevés információt írhatnál, hogy miben lesz ez jobb a már meglévő konkurens termékeknél! Enélkül hogy tudná bárki is eldönteni, hogy áldozza-e rád az idejét vagy sem? Kliens- vagy szerveroldali vagy vegyes?
2

Válasz a részletekre

Steve31 · 2013. Júl. 15. (H), 16.37
Kliensoldalira gondolok, számos keretrendszernél (BackboneJS, EmberJS, stb) bele van integrálva a jQuery. Amit én akarok, hogy minimálisan legyen használva a jQuery, így gyorsabb lesz a rendszer és erőforrásigénye kisebb lesz. A routolása fog még különbözni, mégpedig két-féle lesz. Az egyik olyan lesz mint a többi JS MVC-nél, viszont a másik az a szerveroldali routoláshoz fog igazodni. A második féle routolás még kigondolás van a szürke agysejtekben, de már a körvonalak alakulnak.
3

Ha lassú a jquery

gyoridavid · 2013. Júl. 15. (H), 21.11
vess egy pillantást a Zepto.js-re, 100%-ban kiváltja azt a Backbone-ban
4

Ne

Hidvégi Gábor · 2013. Júl. 15. (H), 22.05
6. sor
String.prototype.trim = function()
Piros fény: ezt tilos használni.

Továbbá: sorok végén nincs pontosvessző. A .html függvény nem takarítja el az eseményvezérlőket. .each függvény.
6

Miért?

Poetro · 2013. Júl. 15. (H), 23.10
Miért baj a String.prototype módosítása? Miért kellene a .html függvénynek eltakarítani az eseménykezelőket? Mi a baj az .each függvénnyel?
9

Miért baj a String.prototype

Hidvégi Gábor · 2013. Júl. 16. (K), 08.46
Miért baj a String.prototype módosítása?
Az Ext.js-t a 3-as vagy 4-es verzióban többek között emiatt írták át. Úgy gondolták, hogy ők majd a prototípusok felülírásával kiegészítik a funkcionalitást, csak aztán kiderült, hogy más is ezt teszi, csak épp nem kompatibilis módon, más paraméterezéssel például, így több JS könyvtár betöltése után valakinek nem működött a kódja.

Miért kellene a .html függvénynek eltakarítani az eseménykezelőket?
Mert ha nem takarítja el valaki, szivárgást okozhat.

Mi a baj az .each függvénnyel?
Redundáns, és lassabbnak gondolom, mint a hagyományos for ciklust, továbbá több memória is szükséges a futtatáshoz.
10

ECMAScript 5

Poetro · 2013. Júl. 16. (K), 08.52
Az ECMAScript 5 szerint a String.prototype.trim-nek nincs egyetlen paramétere sem, nem gondolom, hogy akkor a Zepto vagy Ext.js a hibás, ha tartja magát a specifikációhoz.

Aki .html függvényt vagy .innerHTML-t használ (vagy bármi mást, amivel elemeket távolít el a DOM-ból), az takarítson el maga után.

Az each, attól hogy redundáns és lassabb nem feltétlen rossz. Nem véletlen került be a specifikációba a forEach, map, filter stb. Valószínűleg az emberek igénylik a funkcionális programozást, és szeretik jobban kifejezni, mit is csinálnak, és nem a sebesség az elsődleges. Ha valami kódra a sebesség a fontos, akkor a for illetve while ciklust érdemes használni, de persze:
Premature optimization is the root of all evil
12

Nem tartom szerencsésnek az

Hidvégi Gábor · 2013. Júl. 16. (K), 10.04
Nem tartom szerencsésnek az alapobjektumok prototípusainak módosítását, mert előre nem tudhatod, milyen problémát okoz.

Aki .html függvényt vagy .innerHTML-t használ (vagy bármi mást, amivel elemeket távolít el a DOM-ból), az takarítson el maga után.
Megnéztem, sem a Mozilla, sem a Microsoft dokumentációja nem utal arra, hogy ügyeljünk az események eltakarítására. Tehát nem egyértelmű, ha a Zepto készítői sem tudták ezt, akkor egy átlag halandó még kevésbé fogja, pedig egy webes alkalmazásnál általában elég sok eseményt kell lekezelni, és ezt legtöbbször külön eseménykezelőkkel szokták megoldani.

Ha valami kódra a sebesség a fontos, akkor a for illetve while ciklust érdemes használni, de persze:

»Premature optimization is the root of all evil«
Szerinted a for ciklus használata az előre való optimalizálás?
14

Optimalizálás

Poetro · 2013. Júl. 16. (K), 10.22
Szerinted a for ciklus használata az előre való optimalizálás?

Ha te a programod szándékát jobban ki tudod fejezni valamivel, még ha lassabb is, akkor inkább csináld azt. Az OOP is ilyen. Általában lassabb, de áttekinthetőbb, bővíthetőbb kódot eredményez, ami ellensúlyozza a hátrányait.
17

Ízlések és pofonok különbözőek

Hidvégi Gábor · 2013. Júl. 16. (K), 10.36
for (kulcs in tulajdonsagok) {
  ertek = tulajdonsagok[kulcs];
}

Szerintem ez ugyanolyan átlátható, mint a

$.foreach(tulajdonsagok, function (kulcs, ertek) {
});
7

Ami a pontosvesszőt illeti, a

bamegakapa · 2013. Júl. 15. (H), 23.51
Ami a pontosvesszőt illeti, a szabvány engedélyezi a elhagyását. Bizonyos ritka esetben okozhat problémát, de ha a programozó tisztában van ezekkel az esetekkel és figyel rá, akkor nem látok benne kivetnivalót.

Nagy divat ez most, majd lecseng.

Én mondjuk pontosvesszőpárti vagyok. Csapaton belül is a pontosvesszők kötelező kirakását javasolnám a közös kódolási irányvonalak kialakításánál. De attól még a pontosvessző nélküli nem feltétlenül rossz kód.
8

Nekem volt szerencsém

MadBence · 2013. Júl. 16. (K), 00.12
Nekem volt szerencsém debugolni olyan kódot, ami egy ilyen pontosvessző miatt nem ment :).
(function() {
    /** do awesome stuff */
})()

(function() {
    /** do more awesome stuff */
})()

//vs

(function() {
    /** do awesome stuff */
})();

(function() {
    /** do more awesome stuff */
})()
(nekem így logikusabb a zárójelezés, mielőtt valaki belekötne)
11

Úgy látszik ez a programozó

bamegakapa · 2013. Júl. 16. (K), 09.57
Úgy látszik ez a programozó nem volt tisztában azzal, mire kell figyelni, ha már követi a divatot :). Önhívó függvények elé ki szoktak rakni egy pontosvesszőt, ha jól emlékszem:
;(function() {  
    /** do awesome stuff */  
})()
13

Ez ekvivalens azzal, mintha a

Hidvégi Gábor · 2013. Júl. 16. (K), 10.05
Ez ekvivalens azzal, mintha a hívást megelőző sor végére tennél pontosvesszőt.
15

Én nem állítottam, hogy nem

bamegakapa · 2013. Júl. 16. (K), 10.23
Én nem állítottam, hogy nem az :).

Ez bizonyos esetekben amúgy is hasznos trükk lehet, ha például használsz a projektedben mások által készített Javascript fájlokat (amikben potenciálisan hiányozhat az utolsó pontosvessző), és később össze akarod majd fűzni az összes szkriptet egy fájllá.
16

Összefűzés

Poetro · 2013. Júl. 16. (K), 10.30
Akkor az összefűző script-be raksz ;-t minden egyes fájl után.
18

Jogos, úgy a legtisztább.

bamegakapa · 2013. Júl. 16. (K), 10.57
Jogos, úgy a legtisztább.
5

Backbone's only hard

inf · 2013. Júl. 15. (H), 22.24
Backbone's only hard dependency is Underscore.js ( >= 1.4.3). For RESTful persistence, history support via Backbone.Router and DOM manipulation with Backbone.View, include json2.js, and either jQuery ( >= 1.7.0) or Zepto.


Egyáltalán nincs beleintegrálva a jquery. Csak a $ függvényt használja belőle azt hiszem.

A szerver oldali routolás fogalmát ebben a kontextusban nem tudom értelmezni. Ami a kliensen van routing az csak nagy vonalakban hasonlít a szerver oldali rest service routingjára.