Czesc, ostatnio spotkalem sie ze stwierdzeniem, ze wykorzystywanie wszystkich ficzerow z frameworka, tylko dlatego, ze napiszemy mniej kodu, jest blednie, poniewaz wtedy ten kod jest ciezej przeniesc na inne platformy. Co o tym myslicie ?
0
0
To języka czy frameworka?
Jest mnóstwo czynników wpływających na to jakie jest najlepsze użycie danego narzędzia(czas, budżet projektu, umiejętności zespołu, co to za narzędzie, czy stoi za nim duże community/fundusze itd.). Sądzę, że nie da się tego tak ogólnie podsumować - 'zawsze rób tak a nie inaczej'.
Podaj konkretny przykład, sytuacje i problem - to będziemy mogli jakoś sensownie podyskutować :)
1
Używanie w 100% ficzerów danego frameworka nie jest błędem samo w sobie. Problem zaczyna się, gdy wszędzie wciskasz rzeczy/rozwiązania specyficznedla danego frameworka, a co gorsza mieszasz to z logiką biznesową. Jak kiedyś napotkasz ścianę i będziesz chciał przepisać system na inny framework, użyć innego ORM'a itd. to będziesz miał full kodu do przepisania, a na to nie ma czasu.
Zacytuję @LukeJL, bo uważam, że dobrze to wytłumaczył.
Brakuje też również sensownej architektury. Jeśli ludzie zawierzają frameworkowi w 100% i np. wciskają całą logikę biznesową w dyrektywy Angulara czy do komponentów React to mają problem - przy takim podejściu przepisanie projektu z jednego frameworka na drugi (np. Angulara na React) staje się niemożliwe, gdyż trzeba byłoby przepisać cały kod, co zajęłoby z pół roku, a na to nie ma czasu.
Dlatego lepiej jednak zachowywać jakąś rozsądną separację (np. warstwa widoku oddzielona od logiki) i nie pisać całego kodu we frameworku, ale tworzyć też moduły w czystym JavaScript, które będą definiować logikę aplikacji.
Wtedy nawet używając frameworka, można pisać w ten sposób, żeby dało się łatwo go wymienić.
(...) zbytnio polegałem na bibliotece Rx w komunikacji między modułami, co okazało się błędem, bo ciężko mi teraz pozbyć się Rx.
0
tylko dlatego, ze napiszemy mniej kodu, jest blednie, poniewaz wtedy ten kod jest ciezej przeniesc na inne platformy
jak to mówi Rumpelstiltskin z serialu "Once upon a time" - "all magic comes with the price".
Cena może być różna. Czasem jest taka jak mówisz (problemy z przenoszeniem na inne platformy, które czegoś nie obsługują - ew. obsługują to, ale w inny sposób), czasem inna.
Ceną może być np. wielkość bundla w kilobajtach, może być gorsza szybkość działania, może być trudność w utrzymaniu kodu, może być próg wejścia nowej osoby do projektu (np. używanie wszystkich ficzerów ES6/ES7 etc. w projektach może sprawić, że wchodzący do takiego projektu junior developer się trochę pogubi), ceną może być również większa podatność na bugi itp. No i wreszcie ceną może być np. dodatkowa zależność w postaci konieczności dołączenia jakiejś dodatkowej biblioteki do projektu.
Całe programowanie to nieustanny rachunek zysków i strat. Jeśli "napiszemy mniej kodu" to trzeba się zastanowić jakim kosztem (np. w AngularJS pisanie "mniej kodu" łączyło się np. z tym, że pod spodem się uruchamiała jakaś magia i trudno było to zdebugować - chyba, że ktoś się znał na tym frameworku, ale to znowu dodatkowy koszt w postaci czasu poświęconego na naukę).
Tylko, że często człowiek najpierw musi czegoś spróbować, żeby potem wyrobić sobie zdanie na jakiś temat i poczuć na własnej skórze problemy, jakie mogą wyniknąć z zastosowania czegoś.
No i tak jak pisałem zacytowany - pełna wiara we frameworki się nie opyla, bo nigdy nie masz pewności, czy nie będzie kiedyś trzeba przepisać aplikacji na inny framework (a wszystkie frameworki są kijowe, bo nie ma złotego środka)
0
używanie wszystkich ficzerów ES6/ES7 etc. w projektach może sprawić, że wchodzący do takiego projektu junior developer się trochę pogubi
Sam jestem juniorem i przepisuje projekt na sensowniejszy ES6/7 bo wczesniej byly tylko arrow functions :D Ogolnie przepisuje apke ( wlasciwie modul ) na angular 1.5.x, ale nie chce go pisac w 100% w stylu angular 1, bo nie wiem czy ten modul nie bedzie wykorzystywany w nowym projekcie (angular 2) i jeszcze kolejnym (byc moze react).
Wiem ze ten modul byl przepisywany z jQuery na angulara, ale do tego angularowego doszlo sporej logiki. Niestety jest to splatane z widokami, kontrollerami i jest masakra. Na swiezo upieczonego (2 miechy) juniora padlo przepisanie tego. Ale, ze cos tam w glowie mam i mysle przyszlosciowo, szczgolnie jak slysze ciagle "trzeba sie przerzucic na angular 2 kiedys" , "react by to zrobil lepiej" to napisanie tego w angularze w 100% bedzie failem.
Dlatego staram sie podchodzic minimalistycznie do jakiej kolwiek wiekszej logiki w komponentach/dyrektywach, niektore komponenty sa tylko na zasadzie "presentational", daj jakis index/wartosc, serwis zdecyduje jak to ma zadzialac, a pozniej odpowiednio wrzucic do komponentu.
Mam jeszcze takie jedno pytanie, bo nie wiem czy warto przechodzic na ES7 patrzac na support/predkosc i ogolnie, czy to nie za szybko. Tak bardzo mi sie podoba ES7, ze az zal mi nie wrzucic tego do projektu, bo na przyklad mamy taki case:
<div
ng-mouseover="$ctrl.someOne() && $ctrl.select(index,true)"
ng-mouseleave="$ctrl.someOne() && $ctrl.select(index,false)"
ng-click="$ctrl.someOne() && $ctrl.click(index)">
</div>
class A {
someOne() {
//wakalaka
}
select(index){
//wakalaka
}
click(index){
//wakalaka
}
}
A dzieki dekoratorowi moglibysmy miec takiego cos:
<div
ng-mouseover="$ctrl.select(index,true)"
ng-mouseleave=" $ctrl.select(index,false)"
ng-click="$ctrl.click(index)">
</div>
class A {
@someOne()
select(index){
//wakalaka
}
@someOne()
click(index){
//wakalaka
}
}
W tym przypadku i tak jest dobrze, bo logika w template jest mala, ale wiem, ze projekt ktory przepisuje teraz ma jej sporo, oj bardzo sporo, sa ciezkie warunki :D
A przy okazji chce uniknac czegos takiego jakbym zdecydowal sie na template we wersji 2:
class A {
someOne() {
//wakalaka
}
select(index){
if(this.someOne())
//wakalaka
}
click(index){
if(this.someOne())
//wakalaka
}
}
0
Co do pytania z tytułu - nie warto, przynajmniej jeśli chodzi o JS (nie bez powodu powstają książki typu "The Good Parts"). Część konstrukcji prowadzi do nieczytelnego, trudnego w utrzymaniu kodu. Kod wg mnie powinien być prosty, czytelny i deklaratywny, bez wielu ruchomych części, z tego powodu nie używam raczej takich rzeczy jak:
-
var,let, - imperatywne pętle (
for,while), - metody mutujące kolekcje (np.
Array.prototype.push,Array.prototype.pop,Array.prototype.shift,Array.prototype.unshift,Array.prototype.splice, operatordelete, - callbacki,
-
this, - klasy i prototypy,
- triki typu
~~1.23,+NumberAsString,'' + 1.23, - operatoty
typeofiinstanceof, - wielokrotny
return(poza guard statements), - i pewnie inne rzeczy o których teraz nie pomyślałem.
Ostrożnie podchodzę też do takich rzeczy jak generatory, proxy itp - używam tam gdzie naprawdę jest widoczny zysk.
Co do framaworków - zgadzam się, że zbytnie uzależnianie sie od nich nie jest korzystne, ale to ogólnie cecha frameworków. Wolę stosować biblioteki (i też nie dodaję nowych na pałę, tylko po "rachunku zysków i start".