czyli oparte na prototypach czy klasach? jak obecnie tworzy się aplikacje webowe? czy jeszcze korzysta się z prototypów? jakie są zalety i wady korzystania z prototypów w porównaniu do klas?
czy warto uczyć się jeszcze prototypów? osobiście wolę klasy niż prototypy...
0
1
- TypeScript kompiluje sie do javascriptu, wiec pod spodem caly czas jest to dziedziczenie protototypowe, z tym, ze podrasowane tak, zeby przypominal dziedziczenie z c#, czy javy.
- aplikacje webowe tworzy sie jak tobie/twojemu zespolowi wygodniej
- tak, korzysta sie
- https://stackoverflow.com/questions/19633762/classical-inheritance-vs-protoypal-inheritance-in-javascript, ogolnie uwazam ze prototypowe jest bardziej smieciarskie, ale znowuz ma wieksza moc.
- warto
0
czyli oparte na prototypach czy klasach?
Żeby mieć klasy nie musisz używać TypeScript. W JS (od wersji ES6) też są już klasy.
czy jeszcze korzysta się z prototypów?
Tak, niezależnie od tego czy się robi od wierzchu na prototypach czy klasach, i tak pod spodem będą prototypy.
czy warto uczyć się jeszcze prototypów?
Tak. Koniecznie, bo tak działa JavaScript. Żeby w JS działać sprawnie na klasach, trzeba rozumieć też prototypy. Klasy w JS nie są alternatywą dla prototypów, tylko raczej opakowaniem na prototypy. Nie uciekniesz od tego.
BTW można w ogóle nie używać ani klas ani prototypów, żeby programować obiektowo, np.:
const someObject = {
someMethod() {
}
};
też masz obiektówkę, a nie musisz się bawić ani w prototypy ani w klasy.
jak obecnie tworzy się aplikacje webowe?
Na każdy możliwy sposób. W każdym zespole inaczej i za rok inaczej niż dzisiaj, bo co innego będzie modne.
0
Jak w takim razie pisac w JS pod wszystkie przegladarki ? Tak żeby scrypt uruchamiał się pod wszystkimi wersjami JS?
0
Jak chcesz wspierać stare przeglądarki, to jest takie coś Babel, co transpiluje kod nowszy na starszy https://babeljs.io/
0
LukeJL napisał(a):
Jak chcesz wspierać stare przeglądarki, to jest takie coś Babel, co transpiluje kod nowszy na starszy https://babeljs.io/
Dzieki, chyba wejde w JS na powaznie. Biorac pod uwage ile wyciaga JS- frontdev...warto ;).
0
Niedługo przestanie XD Teraz każdy chce być frontem, więc pewnie niedługo będzie przesyt.
1
Karmel napisał(a):
oparte na prototypach czy klasach?
Ani to, ani to ;)
Wolę kompozycję za pomocą factory functions lub podejście funkcyjne (no dobra, czasem napiszę klasę jak robię coś w Reakcie, choć preferuję stateles components - czyli tez fabryki).
0
niedługo będzie przesyt
Raczej odfiltrowanie prawdziwych frontendowców od januszy. Prędzej czy później klient się pozna, że za parę koła można mieć praktyczną witrynę a nie zerżnięty gotowiec naszpikowany błędami (tego ostatnio niestety jest dość sporo..)
1
Ani to, ani to ;)
Wolę kompozycję za pomocą factory functions lub podejście funkcyjne (no dobra, czasem napiszę klasę jak robię coś w Reakcie, choć preferuję stateles components - czyli tez fabryki).
Moim zdaniem zalezy co piszemy.
0
LukeJL napisał(a):
Niedługo przestanie XD Teraz każdy chce być frontem, więc pewnie niedługo będzie przesyt.
Sporo front-endów ogranicza się tylko do: html, css, bootstrap, JS, query.
Na javowca też każdy się pcha - szczególnie studenci, a zapotrzebowanie wciąż największe.
Trzeba też uwzględnić, że Node ma duży potencjał, popularność z roku na rok rośnie, może wyprzedzić PHP.
0
Biały Szewc napisał(a):
Ani to, ani to ;)
Wolę kompozycję za pomocą factory functions lub podejście funkcyjne (no dobra, czasem napiszę klasę jak robię coś w Reakcie, choć preferuję stateles components - czyli tez fabryki).Moim zdaniem zalezy co piszemy.
No w szczególnych przypadkach tak (albo jak framework wymusza), ale zwykle apka nie wymaga konkretnego rozwiązania, więc można wybrać to, które Ty i Twój team wolicie.
Klasy są szybsze i mniej pamięciożerne, ale często jest to tylko ułamek wydajności aplikacji, pomijalna mikrooptymalizacja. Klasy i prototypy są natomiast bardziej skomplikowane, trudniej je komponować, trudniej sterować zasięgiem zmiennych (http://2ality.com/2016/01/private-data-classes.html), łańcuch prototypów jest mniej czytelny od płaskiej struktury, klasy zachęcają do szkodliwego moim zdaniem dziedziczenia.
Dlatego ja kiedy mogę to wybieram rozwiązanie prostsze i posiadające mniej magii.
0
Sporo front-endów ogranicza się tylko do: html, css, bootstrap, JS, query.
Wg mnie powinno się ograniczać, ale nie do Bootstrapa czy jQuery, tylko do triady
- HTML (+SVG)
- CSS
- Javacript (+ API przeglądarkowe).
Całą reszta to tylko nakładka i można sobie ją wyprowadzić z całej reszty. Znasz HTML + CSS + JS? No to poznasz łatwo jQuery, Reacta, Angulara, cokolwiek, bo koniec końców i tak to się opiera na JS, HTML, CSS.
0
No w szczególnych przypadkach tak (albo jak framework wymusza), ale zwykle apka nie wymaga konkretnego rozwiązania, więc można wybrać to, które Ty i Twój team wolicie.
Klasy są szybsze i mniej pamięciożerne, ale często jest to tylko ułamek wydajności aplikacji, pomijalna mikrooptymalizacja. Klasy i prototypy są natomiast bardziej skomplikowane, trudniej je komponować, trudniej sterować zasięgiem zmiennych (http://2ality.com/2016/01/private-data-classes.html), łańcuch prototypów jest mniej czytelny od płaskiej struktury, klasy zachęcają do szkodliwego moim zdaniem dziedziczenia.
Dlatego ja kiedy mogę to wybieram rozwiązanie prostsze i posiadające mniej magii.
Moim zdaniem podejscie funkcyjne ma spoko ficzery z ktorych sie fajnie korzysta w obiektowym podejsciu, mysle tu o backendzie. Jakos na froncie lepiej mi sie pisze (a przynajmniej staram sie pisac) funkcyjnie, na backendzie mi nie podchodzi, poza wlasnie tymi ficzerami.
klasy zachęcają do szkodliwego moim zdaniem dziedziczenia.
owszem, ale po to sie projektuje aplikacje tak, aby to bylo niemozliwe / trudne i powiedziec programiscie, ze chyba robi cos nie tak. Nie jestem tak obiegany w programowaniu funkcyjnym, ale dobre IDE + podejscie obiektowe w jezykach nie kaczo-typowanych i z olejem w glowie pozwala na szybsza prace i zrozumienie dzialania aplikacji niz g(f(x)) x 300. I dlatego wlasnie mowilem, zalezy co piszemy. Teraz pisze w react + d3 i takie podejscie jest zarabiste (funkcyjne). Nie wiem moze za cienki jestem w te klocki ;)
1
Biały Szewc napisał(a):
dobre IDE + podejscie obiektowe w jezykach nie kaczo-typowanych i z olejem w glowie pozwala na szybsza prace i zrozumienie dzialania aplikacji niz
g(f(x)) x 300
No jak OOP jest zrobione dobrze to pewnie tak, bo podany przykład jest akurat słaby, mozna pisać tak:
const doSomething = x => { /* ...some operations */ }
const doSomethingElse = (x, y) => { /* ...some operations */ }
const doAnotherThing = (x, z) => { /* ...some operations */ }
const result = doAnotherThing(doSomethingElse(doSomething(mainArgument), param1), param2)
A można też tak (z użyciem compose/pipe/flow):
const doSomething = x => { /* ...some operations */ }
const doSomethingElse = y => x => { /* ...some operations */ }
const doAnotherThing = z => x => { /* ...some operations */ }
const doComplexThing = pipe(
doSomething,
doSomethingElse(param1),
doAnotherThing(param2)
)
const result = doComplexThing(mainArgument)
Oczywiście w obu przypadkach zmienne powinny się lepiej nazywać ;)
Może po prostu widziałes brzydkie przykłady FP, zarówno wśród zwolenników OOP jak i FP znajdziesz fanów zaciemniania kodu ;)
0
Z drugiej strony niektórzy przesadzają. Np. bardziej zaawansowane rzeczy w Redux typu middleware zawsze mnie odstraszają tą wielopoziomowością, funkcja, która zwraca funkcję, która zwraca funkcję... czy jakoś tak. Może i to fajne, może i to cool, ale dla mnie to trochę Perl się robi z tego - też niby fajny język (mnie się bardzo podobał) i wyrażenia regularne też bardzo fajna sprawa - ale jednak wyrażenia regularne nie są zbyt czytelne, tak samo jak zbyt skomplikowany control flow w programowaniu funkcyjnym.
0
@LukeJL
To tylko i wyłącznie kwestia poznania i oswojenia się z paradygmatem funkcyjnym (currying w tym wypadku).
[...] middleware zawsze mnie odstraszają tą wielopoziomowością, funkcja, która zwraca funkcję, która zwraca funkcję... czy jakoś tak.
Jeśli analizujesz to w ten sposób to rzeczywiście może się to wydawać zgmatwane (też mi się tak na początku wydawało), ale można na to spojrzeć w dużo prostszy i praktyczniejszy sposób, weźmy przykładowy middleware Reduksa:
const logger = store => next => action => {
// ...some logging
return result
}
// example usage:
logger(store)(next)(action)
Dla mnie to nic innego jak (podrasowane):
const logger = (store, next, action) => {
// ...some logging
return result
}
// example usage:
logger(store, next, action)
Czyli funkcja przyjmująca trzy argumenty (i w istocie w językach z automatycznym curryingiem takich jak F#, Haskell itp. te funkcje są sobie równoważne*). Zaleta jest taka, że robiąc taki ręczny currying w JS możemy (choć nie musimy) zastosować partial application, dzięki czemu da się ładnie komponować funkcje, robić DI itd
*Przykład równoważnego kodu w F#
// wersja 1: pojedyncza funkcja z trzema argumentami
let logger store next action = (* ...code *)
// wersja 2: trzy zagnieżdżone, jednoargumentowe lambdy
let logger = (fun store -> (fun next -> (fun action -> (* ...code *)))
// obie wersje możesz wywołać tak samo (stąd brak nawiasów w wywołaniach w F#)
logger store // partial with only store provided
logger store next // partial with store and next provided
logger store next action // full function call