ugrás a tartalomhoz

Mennyi idő szükséges a junior front-end fejlesztő szint eléréséhez?

Andi20 · 2017. Jún. 7. (Sze), 20.28
Mennyi idő szükséges a junior front-end fejlesztő szint eléréséhez? Hol/ milyen felületen (videó, tanfolyam) tudnám megtanulni ezeket? Ezenkívül a front-end vagy a back-end fejlesztés az egyszerűbb tanulás/idő szempontjából?
A jövőben front-end fejlesztőként szeretnék dolgozni.
Már rendelkezem HTML, CSS, Bootstrap, Javascript/JQuery, Joomla és némi PHP és QSL ismeretekkel.
Szükséges még megtanulnom az Anguar.js-t, node.js-t, SASS/LESS-t.
 
1

Idő

janoszen · 2017. Jún. 7. (Sze), 21.15
Szerintem ez nem idő kérdése. Van, aki 2-3 hónap alatt felszed hihetetlen mennyiségű tudást és ezzel már munkakörnyezetben is bevethetővé válik. Az is kérdés, hogy milyen céghez mész. Egy weblapgyáros Kft-nél sokkal alacsonyabbak a követelmények mint egy hosszú távú karbantarthatóságra koncentráló fejlesztőcégnél.

Ha én Te lennék, akkor most megpróbálnék egy React, Redux, React Router és webpack stacket összerakni és azzal munkát szerezni, az most menő.

A videótól óva intenélek, nagyon sok kezdő úgy gondolja hogy elég az ha megnéz egy videót, de tényleg megtanulni akkor fogod, ha használod is. Az sem feltétlenül baj, ha debugolásnál nem nézel tanácstalanul hogy mi az a HTTP és abba hogyan kell belenézni.
4

Összesen kb +10 :)

Pepita · 2017. Jún. 8. (Cs), 08.30
React, Redux, React Router és webpack stack

+ React native mobilra.
Valóban menő, de elég elterjedt (volt) knock out is, munka szempontjából jó lehet.

weblapgyáros Kft

Hát ezen a cégneven majdnem besírtam, de azért mégis komolyabb cégnek tűnik, mint a Vér Pistike Hungary Bt. :-D

Összességében nagyon egyetértek.
2

Relatív

Hidvégi Gábor · 2017. Jún. 8. (Cs), 06.47
Ha megnézek a weben bármely weboldalt, akkor elég gyorsan kiderül, hogy a frontend fejlesztők túlnyomó többsége (99,99999%) még nem érte el a junior szintet, annyira rossz minőségű, amit kiadnak a kezükből. Általában nem értik, hogyan működnek a böngészők, mit (nem) érdemes javascripttel megvalósítani, nem tudnak algoritmikusan gondolkodni, fogalmuk sincs, milyen alternatív lehetőségek vannak css-ben, nem tudják, hogyan lehet gyors kódot készíteni.

Ez könnyen tűnhet fellengzős szövegnek, de nem véletlenül jött létre a Google AMP projekt, ahol ezek egy részét bizonyos szabályok megalkotásával próbálják orvosolni.

Ez az egész köszönhető részben a fejlesztők felkészületlenségének, de annak is, hogy a web mára túl komplex-szé vált, és egyre nehezebb átlátni. Szép dolog a szabadság, de ha túl sok minden között lehet dönteni, nem lesz egyszerű meghozni a legjobbat.

---

Ha szeretnél jó kódot készíteni, az olyanokat, mint a React, Angular és társaik messziről kerüld el. Pártíz kilobájtból lehet olyan keretrendszert készíteni, ami sokkal jobb lesz, egyszerűbb, jóval kevesebb kompromisszummal és munkával fog járni, és nem leszel kitéve a többi még-nem-junior fejlesztő szeszélyeinek.
3

Bár nem vagyok frontend

BlaZe · 2017. Jún. 8. (Cs), 07.32
Bár nem vagyok frontend fejlesztő, de abban egész biztos vagyok, hogy nem jó tanács a piacon a 2 jelenleg legkeresettebb frameworkről lebeszélni valakit, aki el szeretne helyezkedni... Legtöbb projecten nincs idő újra feltalálni a kereket, és olyan dolgokkal tölteni az időt
1) amit egy külsős nem ismer, tehát a betanulási idő sokkal hosszabb lesz egy új kollégánál
2) ami növeli a time to marketet, hiszen van rá polcról levehető megoldás, ami tökéletesen megfelel
3) mint a bugok felfedezése, debugolása, javítása

Legtöbb projecten eladhatatlan és kivitelezhetetlen, amit tanácsolsz. Nem árt tudnia mi van a háttérben, ezzel egyetértek. De a piacon lévő vezető technológiákat tudni és ismerni KELL.
6

Nem értek egyet

Hidvégi Gábor · 2017. Jún. 8. (Cs), 10.58
Ha valaki tisztában van azzal, hogyan működnek a böngészők, és hogy mennyire primitív a weboldalak/webes alkalmazások 99%-a, akkor nyilvánvaló számára, hogy ezekre a keretrendszerekre nincs szükség, mert
  • lassúak,
  • sok a függőségük és a hatékony munkához szükséges eszközök száma,
  • rengeteg idő a megtanulásuk és a tapasztalatszerzés.
Természetesen mindenki el tudja dönteni, hogy mit szeretne elérni:

a, önálló, felelősségteljes munkakört előrelépési és fejlődési lehetőséggel:

Ekkor melózni kell, tanulni, kísérletezni, rengeteg időt rászánni, de cserébe annyit fog keresni, amennyit akar.

b, egy csinpánz képességeit igénylő melót, ahol kvázi karokat kell húzogatni és gombokat kell nyomogatni (API hívások):

Nem is lesz belőle semmi, mert az önként vállalt korlátokon nem fog tudni túllépni.

Ez következik a fenti keretrendszerek működéséből, amik teljesen elfedik előle a böngészőt, így esélye sem lesz megérteni a működését, esélye sem lesz gyors és kevés erőforrást igénylő szoftvert készíteni, mert hiába nyílt forrásúak ezek, a működésükből adódóan a lehetőségek végesek.

---

Az egész dolog felfogás kérdése: a böngészőből jön egy input (kattintás, szövegbevitel, simogatás stb.), a visszakapott választ pedig meg kell jeleníteni. Ezt az esetek többségében JS nélkül is meg lehet valósítani, ahol pedig szükséges, 10-20 kilobájtnyi kódból fantasztikus dolgokat lehet kihozni. Nincsenek csodák, a legvégén úgyis HTML-t kell írni.
8

Nope

janoszen · 2017. Jún. 8. (Cs), 12.56
Sztem frissits a tudasodon. Ha a Reactot vesszuk, egyik megallapitasod sem igaz, mert:

lassúak,


Gyorsabb mint a kezzel irt kod, mert csak akkor matat a DOM faban ha tenyleg szukseges, es akkor is tombositve.

sok a függőségük és a hatékony munkához szükséges eszközök száma,


npm kell a forditashoz, fuggosegek tekinteteben pedig kevesebb jon vele mint egy atlagos mini Java alkalmazassal.

rengeteg idő a megtanulásuk és a tapasztalatszerzés


Nem vagyok nagy JS magus, megis sikerult a Reactot megtanulni hasznalhato szintere egy delutan alatt. Es nem eroltettem tul magam.
10

Realitás

Hidvégi Gábor · 2017. Jún. 8. (Cs), 14.00
Gyorsabb mint a kezzel irt kod, mert csak akkor matat a DOM faban ha tenyleg szukseges, es akkor is tombositve.
Én már egy ideje nem hiszek az ilyen marketingdumának, mert sajnos elég hamar bebizonyosodik, hogy nincs mögötte semmi.

Éppen ezért fogtam magam, és lemértem, mennyi az az annyi. Vettem a rendszerünkből a Számlák listája űrlapot, annak készítettem el egy egyszerűsített változatát, amely harminc sorból, és soronként negyven űrlapelemből állt, majd azt először kirajzoltam, aztán pedig frissítettem az adatokat.

A következők jöttek ki, a számok ezredmásodpercben értendők, átlagok (az első a render, a második a frissítés):
React: 1280 | 700
Vue:   1050 | 800
XSLT:   350 | 350
Natív:  125 | 125
Chrome ötvenakárhányban.

Összességében messze a leghatékonyabb XSLT-vel dolgozni, bár úgysem hiszed el, de pár kilobájtnyi kódból megvan a renderelés és a teljes eseménykezelés.
11

Nem egy urlap

janoszen · 2017. Jún. 8. (Cs), 14.09
Ne egy oldalt merjel, nyilvan ultrahatekonyan megirod hogy az az egy jol mukodjon, hanem egy admin oldalt tobb szaz gombbal, 30-40 modositasi keres utan. Garantalom neked, hogy az ossze-vissza modositas hatasara a kezi kod jo lassu, es legfokeppen karbantarthatatlan lesz.

Egy par szaz soros kod nem repezentativ, beszeljunk, ha eleri a par ezret, esetleg tizezret.
12

Generális

Hidvégi Gábor · 2017. Jún. 8. (Cs), 15.11
Természetesen teljesen általánosan oldottam meg, ráadásul a natív és az XSLT megoldás brute force, azaz frissítésnél is újrarendereli az egészet, mert sokkal gyorsabb. Van némi rálátásom a problémára, hisz több mint tíz éve egy tetszőleges adattömeggel dolgozó rendszert fejlesztek.

A React, Angular, Vue és társaik egy teljesen elhibázott logikára épülnek, ezért is véreznek el az első vallatásnál.

Például a React komolyságát mutatja, hogy
  • a 0.14.X-es verzió után mindjárt 15-re lépett, itt azért az ember elkezdhet gyanakodni, hogy valami nincs rendben,
  • nincs a sablonozásban rendes feltételes renderelés (if, switch),
  • keveredik a javascript, a sablonozás és az eseménykezelés, pedig a web 2.0 megjelenésekor tizenvalahány éve pont az volt az elmélet, hogy ezeket szét kell választani,
  • ahhoz, hogy használható legyen, egy csomó eszközt kell megtanulni, amit fel is soroltatok fentebb: React, Redux, React Router és webpack stack, React native, npm
13

Ez nem egy szubjektív dolog,

BlaZe · 2017. Jún. 8. (Cs), 19.35
Ez nem egy szubjektív dolog, és nem is technikai. Ezeket a keretrendszereket használják most gyakorlatilag mindenhol. Aki nem ismeri, csökkenti a piaci értékét, és nehezíti az elhelyezkedését, mint front-end, vagy full-stack developer. Ezzel kár vitatkoznod. Innentől meg ez nem egy megfontolt jótanács egy seniortól, hanem egy érzelmi kitörés.

Fizetést azért kapunk, mert értéket teremtünk a megrendelőnek, és azért kapunk magas fizetést, mert ezt hatékonyan (a pénzével optimálisan gazdálkodva) tesszük. Leveszem a polcról és használom a kb standardet, ezzel garantálom, hogy az utódom is érteni fog hozzá: ha lelépek, a megrendelőm/munkáltatóm minimális hiccuppal (elvárhatóan alacsony betanulási költség mellett) tud pótolni. VS saját hegesztett valami, amit csak te ismersz. Szerintem te is látod a különbséget...

Ami az alsóbb szinteket illeti, szerintem is kell tudja mi működik a frameworkök alatt. Egy seniornak. Egy juniortól ne várjuk el, hogy ilyen tapasztalata, és mély tudása lesz. A junior definíciója, hogy vannak általános alapjai, és egy senior támogatása és útmutatásai alapján képes fejleszteni, valamint aktívan tesz érte, hogy felszedje a tudást. Juniortól tehát ne várjuk el, hogy összerakjon egy az említett frameworkökét megközelítő minőségű (sebesség és minőség) sajátot. Az általában senioroknak se megy amúgy :)
15

Nem értek egyet

Hidvégi Gábor · 2017. Jún. 9. (P), 17.28
Nem értek egyet az általad leírtakkal, többek között azért, mert nincs minden megrendelőnek szüksége az említett keretrendszerekben elkészített weboldalra/-szolgáltatásra.

Továbbá a működési jellegükből adódik, hogy mivel nagyon sok mindent elrejtenek a fejlesztő elől, ezért egyrészt bizonyos optimalizálásokat nem, vagy csak nagyon nehezen lehet megvalósítani, másrészt egy csomó technológiai részlettel emiatt nem tudnak megismerkedni.

A végeredmény: egy technológiai korlátokkal rendelkező szolgáltatás és egy karokat húzogató csinpánz. Akkor optimálisan gazdálkodtál a pénzével?

Tehát mind az egyén, mind pedig a cég szempontjából hátrányos, ha React-re, Angulárra és hasonlóakra építik a jövőjüket.

Nem vagyok meggyőződve arról, hogy egy projekt elkészítése ezekben a rendszerekben gyorsabb lenne, mint egy saját fejlesztés, egyszerűen azért, mert túl sok olyan kódot láttam, amit natív eszközökkel fele annyiból meg lehetett oldani, mint akármilyen framework-ben. Mert akárhogy erőlködnek elfedni a dolgokat, a végéredmény úgyis csak GET, POST és HTML lesz.

VS saját hegesztett valami, amit csak te ismersz.
Ki miből indul ki, ugye.

Haha! Angular 1 versus Angular 2. Az Angular következő nagy verziója mennyire lesz kompatibilis a mostanival?
16

Tudom, hogy nem értesz egyet,

BlaZe · 2017. Jún. 9. (P), 17.52
Tudom, hogy nem értesz egyet, különben nem kardoskodnál amellet, amit leírtál.
Egy dologra emlékeztetnélek a közös múltunkból: überadmin :)
Te is megszívtad, én is megszívtam. Nem csak azért, mert hulladék volt az egész, hanem mert mindenkinek meg kellett nulláról ismerje, aki odakerült. Javítgatni kellett business feature-ök fejlesztése helyett stb. Senki nem akar csak egy cégnél használható technológiákat megtanulni. Több embert interjúztam az utóbbi években az egyik legnagyobb itthoni multitól, igen jó poziból és fizetésből, akik ezt jelölték meg első helyen, hogy miért váltanának: olyan dolgokat kell megtanuljanak, amik nem építik a karrierjüket.

Én is írok olyan kódot, meg saját libet, elérhető framework-ökkel szemben. Otthon, a pet projectemen, és mert olyan speciális igényeim vannak, amikhez nagyon limitált library support van. De ez két teljesen külön dolog.

Teljesen objektív tényekkel szemben vitatkozol érzelmi alapon. Így nem megy megint :(
17

Ráció

Hidvégi Gábor · 2017. Jún. 9. (P), 21.53
Bocsánat, akkor először szerintem tisztázzuk az "érzelmi alapon" való érvelés jelentését: ehhez az szükséges, hogy valaki alátámasztás nélküli kijelentéseket tegyen. Hol látsz te itt ilyeneket? Csak mert az én gyakorlati tapasztalataim alapján feltett kérdéseimre, állításaimra nem érkezett értékelhető válasz, de akkor megismétlem őket, hogy ne egyesével kelljen összehalászni:

  • Teszteket végeztem, és a natív kód átlag öt-tízszer gyorsabb, mint a keretrendszerek. Ez Móriczka-projekteknél nem jön elő, de amint egy picivel is bonyolultabb a szoftver, és nem két darab adattal kell dolgozni, azonnal hack-elni kell, és így elveszítik minden előnyüket,
  • A keretrendszerek által elrejtett funkcionalitással (gyorstárazás, DOM műveletek) a fejlesztő nem fog találkozni, így ezekben nem tud tapasztalatot szerezni, így öt-tíz év múlva nem senior fejlesztő, hanem senior React fejlesztő lesz csak belőle, ami nagy különbség,
  • Ez utóbbiból következik, hogy ha változik a szélirány, más keretrendszer jön divatba, akkor a korábbi tudása semmit sem fog érni,
  • A keretrendszerekben történő nagyobb, visszafele nem kompatibilis változások a régebbi projekteket frissíthetetlenné teszik.
---

Mi is keretrendszerrel kezdtünk (Ext.JS), és elég hamar elértük a korlátait, pedig pont arra lett kitalálva, amire nekünk kellett volna, űrlapok összeállítására.
Csak egyrészt képtelenség volt vele azt az adatmennyiséget kezelni, amire szükségünk van, másrészt az alapvető hibáinak a javítgatása rengeteg időt vett el a saját programunk fejlesztésétől.

Emiatt kénytelenek voltunk sajátot fejleszteni, így ismerkedtem meg rengeteg technológiai problémával és a megoldásukkal mind kliens-, mind pedig szerveroldalon, és sokkal nagyobb a rálátásom a szakmára, mintha végig csak Ext.JS fejlesztőként dolgoztam volna.

De nézhetjük úgy is, hogy a rendszerünket bármikor lefejlesztem Angulárban, React-ben vagy Senchában, de egy olyan ember, aki csak ezekben dolgozott, a mi natív rendszerünket sosem tudja elkészíteni.

Nincs itt semmiféle érzelem, amiről írok, az tiszta üzlet.

De nem csak a fejlesztők gondolkodnak különbözően, és sokuk megelégszik a csinpánz szereppel, vannak cégek, akik önálló munkavégzésre és problémamegoldásra képes emberekre van szükségük, mint én. Úgy gondolom, hogy hosszabb távon mindenki ez utóbbi modellel jár jól, hisz a divat elég gyorsan változik.
18

Nem fogok ezekre tételesen

BlaZe · 2017. Jún. 9. (P), 23.58
Nem fogok ezekre tételesen válaszolni. Korábban is leírtam miért nem releváns, amit írsz. De akkor mégegyszer: egy juniornak azt tanácsoltad, hogy azokat a frameworköket ne tanulja meg, amik ismerete piacképessé teszi, és amikkel komoly helyre be lehet kerülni jó fizetésért, hisz az összes komoly helyen is ezeket keresik most. Még azokban az állásokban is szerepelnek ezek a technológiák, amikkel engem megtalálnak. Pedig hát én fényévekre vagyok a front-endtől már évek óta. Ezért mondtam, hogy ez objektíven nézve nagyon nem jó tanács. Ez még akkor is így lenne, ha igazad lenne, és ezek teljesen használhatatlan technológiák lennének. De hát erről szó sincs. Bizonyítottak már ezek komoly helyeken még akkor is, ha te ezt nem akarod belátni (érzelem).

Továbbá a frameworkök használata nem zárja ki a tanulást, és a tudás iránti vágyat, amik valóban szükséges feltételei a mély tudásnak, nem úgy, mint a framework/nemframework.

Na mind1, részemről ennyi volt ez a téma.
19

Tévedsz

Hidvégi Gábor · 2017. Jún. 10. (Szo), 08.37
A kérdező még junior szinten sincs saját bevallása szerint is, lásd a téma címét.

Tapasztalatom és meggyőződésem, hogy az általam leírt módszer (végigjárni az alapoktól a szamárlétrát) minden szempontból jövedelmezőbb választás, mint helyből felugrani a kétharmadra.

És ezzel én is zárom ezt a szálat.
5

mikor hogy..

Pepita · 2017. Jún. 8. (Cs), 08.38
Nagyon picike, fix csapatban, nagyon kicsi projekteken, nagyon egyszerű igények mellett tulajdonképpen frontend sem kell (kb kihánysz vmi html-félét), de ha ezek közül egyik nem igaz - akár csak egyetlen -, akkor máris szüksége lesz a szerinted kerülendő "olyanok" valamelyikére. Ha ezt szakmaszerűen szeretné csinálni, akkor mindegyik "divatos" fw-re.
7

React

janoszen · 2017. Jún. 8. (Cs), 11.48
Ha szeretnél jó kódot készíteni, az olyanokat, mint a React, Angular és társaik messziről kerüld el.


Max akkor ha csak nehany animalt bannert kell keszitened. Ha komolyabb admin feluletet kell osszeraknod mindenfele dinamikus akcioval es par szaz gombbal (adjunk hozza sorokat, kezeljunk hibakat, stb) a sajat frameworkodben meg kellene oldani az adatmodelled es a DOM fa kozotti szinkronizalast, ami nem nevezheto trivialisan egyszeru feladatnak. Ha ezt nem csinalod meg, akkor nagyon gyorsan nagyon nagy katyvasz lesz az egesz, mert JavaScript kodban keresztul-kasul turkalni a DOM faban nem jo buli, olvashatatlanna teszi a kodot, raadasul sokkal lassabb mint ha szinkronizaltan, egyszerre hajtanad vegre a modositasokat.

Ha ilyen tanacsot adsz egy kezdonek, akkor elkergeted a jQuery iranyba es az senkinek nem jo.
9

Egy kezdő nem fog komolyabb

Hidvégi Gábor · 2017. Jún. 8. (Cs), 13.06
Egy kezdő nem fog komolyabb adminfelületet összedobni, mert még a létra elején van.

a sajat frameworkodben meg kellene oldani az adatmodelled es a DOM fa kozotti szinkronizalast, ami nem nevezheto trivialisan egyszeru feladatnak
Mi nehéz benne? Végig kell iterálni az adatokon, és el kell készíteni belőle a HTML-t.
20

a sajat frameworkodben meg

Hidvégi Gábor · 2017. Jún. 10. (Szo), 09.40
a sajat frameworkodben meg kellene oldani az adatmodelled es a DOM fa kozotti szinkronizalast, ami nem nevezheto trivialisan egyszeru feladatnak
Ez nagyon bántja a szemem.

Bármely diszkrét időpillanatot nézzük, adottak a memóriában lévő adataid, valamint tudod azt, hogy azokat hogyan kell megjeleníteni – azaz léteznie kell egy függvénynek, amivel a transzformációt el lehet végezni.

Ebből sokminden következik:
  • Azokat az elemeket, amelyek tartalma változhat, algoritmizálható egyedi azonosítóval kell ellátni
  • Ezeket az adatmodellből kell származtatni
  • Ha az előző kettő teljesül, akkor könnyedén megoldható bármely egyedi elem cseréje
  • Tapasztalatalatom, hogy nyugodtan lehet képernyőnyi blokkokat is felülírogatni, gyors lesz, de természetesen egyszerű egy saját diff-et írni, mert adja magát
Maga az algoritmus ennyire egyszerű, megnéztem a saját megoldásomat, 1419 bájtban valósítottam meg, a többi csak a körítés (kérés elküldése, válasz feldolgozása).

Ebből az is következik, hogy a legegyszerűbb a funkcionális megvalósítás, procedurálisan ez jóval lassabb és kevésbé átlátható lesz (lásd React versus saját eredményeim).
21

Ugyanazokat a köröket futjuk sok-sok éve már...

T.G · 2017. Jún. 10. (Szo), 11.54
Nekem csak egy kérdésem lenne. Gábor, elolvasva az előző hozzászólásokat, te látsz benne bármi új információt, amelyet eddig nem ismert volna a „törzsközönség”? A témanyitó természetesen új felhasználó, ám nem is neki válaszoltál, ő framework-ökről érdeklődött, te pedig minden másról írtál. De számomra nem is ez az érdekes, most már tényleg tökre érdekelne, hogy mi a fenét vársz te ettől a szélmalomharctól, amit itt csinálsz?
Nem akarok a pszichológusod lenni, csupán érdeklődöm, hogy ha ezt a nagy energiát valami hasznosabbra fordítanád, akkor nem képzelhető el, hogy valami értékteremtőt is alkothatnál?
22

:-) :-) :-)

inf · 2017. Jún. 10. (Szo), 17.25
:-) :-) :-)
25

Tévedsz

Hidvégi Gábor · 2017. Jún. 10. (Szo), 17.42
Kettes számú hozzászólásomban azt tanácsoltam neki, hogy írjon sajátot.
26

Szuper!

T.G · 2017. Jún. 10. (Szo), 18.59
Szuper, és sikerült a lényeget kivenni az üzenetemből! :)
27

Haszon

Hidvégi Gábor · 2017. Jún. 10. (Szo), 21.15
Az, hogy az életemben mi hasznos és mi nem, majd én eldöntöm.

Az itt felsorakoztatott érveimet a saját weboldalamon prezentáltam korábban, amire janoszen indított egy saját fórumtémát, azt, valamint a site-om scriptjeinek forráskódját érdemes átnézni.

Minden este azon dolgozom, hogy további különböző példákkal támasszam alá az elvet. Amint kész lesznek, prezentálom, addig próbáld meg megérteni az elméletet.

Várom a témában a kérdéseidet.
28

Minden este?

T.G · 2017. Jún. 10. (Szo), 21.42
Persze, mindenki azzal cs.szi el az idejét, amivel akarja. Én is például most itt írom ezt a hozzászólást, én most épp ezzel. De van bennem egy perverz kíváncsiság, hogy megértsem a motivációdat! Arról már régen letettem, hogy az érveidet megértsem, engem már csak a motivációd érdekel. És valóban semmi közöm hozzá, ám egy enyhe utalást azért szerettem volna tenni, hogy miközben a hatékonyságról megy itt a vita, aközben ez a küldetésed kívülről úgy néz ki, mintha a hatékonyság megcsúfolása lenne. Hány éve, milyen eredménnyel? Mondjuk, ezen az összképen csak tovább ront az a plusz információ, hogy minden este ezen dolgozol. Minden este? Ez durva. És még az összefoglaló cikket is más írta. Ez tényleg durva.
29

Motiváció

Hidvégi Gábor · 2017. Jún. 10. (Szo), 21.52
Te vagy a motivációm, mert te kértél bizonyítékot a korábban kifejtett érveim alátámasztására, hisz azokat szemmel láthatólag egyikőtök sem értette meg.

És ha már csinálok valamit, akkor azt rendesen csinálom, úgy, hogy mindenkinek átmenjen.

Miért tart ilyen sokáig? Mert idő megismernem az Angular, a React és társaik működését, idő, amíg az összehasonlító teszteket elvégzem, idő, amíg a példákat elkészítem.
30

Megtisztelő! :)

T.G · 2017. Jún. 10. (Szo), 22.01
Komolyan, ezen most jót nevettem! Ez több mint megtisztelő! :)
A meghatottságtól szóhoz sem jutok! :) Ám, ha már ilyen megtisztelő szerepem van ebben, akkor mégiscsak ajánlanám, hogy indíts egy blog-ot, ahol a részeredményeket minden este kipublikálhatnád. Ma már több ezer bejegyzés lenne azon a blog-on…
31

Miért?

Hidvégi Gábor · 2017. Jún. 11. (V), 11.51
És az miért is lenne jó?
32

Komolyabban lehetne venni...

T.G · 2017. Jún. 11. (V), 19.05
Komolyabban lehetne venni a törekvést, ha nem csak ígéreteket kapnánk, hanem részeredményeket is, amelyre kiváló felület lenne egy önálló oldal, vagy példának okáért egy önálló blog.
Illetve, ha nem mások gondolataira reagálsz, hanem saját magad alkotod meg a tematikát, akkor nem lenne ennyi felesleges ismétlés.
33

Jól van

Hidvégi Gábor · 2017. Jún. 11. (V), 20.41
Majd átgondolom.
34

Igazad van, elég lenne csak

inf · 2017. Jún. 11. (V), 22.20
Igazad van, elég lenne csak belinkelni az adott szekciót a lefektetett alapelvre, felesleges lenne mindent százszor újra és újra leírni. Így egy csomó idő és energia szabadulna fel a rendszer fejlesztésére. Ugye ez is olyan, mint a kód újrahasznosítás.
14

Időt nem igazán lehet

Iamzozo · 2017. Jún. 8. (Cs), 22.53
Időt nem igazán lehet jósolni, de mivel a junior állás a cél, szerintem Angular és React játszik. Ezek most a trendi cuccok - népszerűek, preferált a cégeknél is, ha ismered, jobban el tudod adni magad.

Nekem a legjobb bevált módszer a github és a doksik. Letöltesz vmi kis alkalmazást, beüzemeled, átírod, nem érted, olvasol, írsz bele megint, már kezded érteni és így tovább.

Framework/library:
Angularra: angular-university.io
Vue: laracasts.com (itt vannak külön vue-s tutorialok és nagyrésze elérhető ingyen, de egy előfizetés sem a világ kincse)
React: nem használtam még, nincs konkrét ajánlat

Build tool:
Webpack - ezég elég valószínű hogy marad egy darabig

Példák:
TodoMVC - érdemes képben lenni az aktuális (és nem aktuális) trendekkel is:
https://github.com/tastejs/todomvc


Egyéb:
- ES6
- SASS
- REST, JSON RPC - ezt jó érteni frontendesként

Mi a cégnél most váltottunk angular 1-ről 4-re (2.4-re, khm.), ez alapján kerestünk kollégát is. Epam-nál is pl angularoznak. Szóval ha ezen a területen indulsz el, rosszba nem vágsz.

Én itton mondjuk vue.js-el szeretek mókolni, de ez nem túl elterjedt.
24

Webpack-ről tudnál írni

inf · 2017. Jún. 10. (Szo), 17.34
Webpack-ről tudnál írni néhány sort, hogy hogyan érdemes nekiindulni? Én leragadtam browserify-nál. Nem mondom, hogy rossz lenne, de azért szeretnék haladni a korral, és webpack-et valamiért nem sikerült normálisan bekonfigurálnom, amikor legutóbb próbálkoztam vele.
35

Kicsit megkésve..

Iamzozo · 2017. Aug. 7. (H), 18.31
https://gist.github.com/iamzozo/27b9c1c6d5057bb8c9fc9a9bcf22d8f5
36

Köszi!

inf · 2017. Aug. 7. (H), 22.20
Köszi!
23

Angular-nak és React-nek

inf · 2017. Jún. 10. (Szo), 17.32
Angular-nak és React-nek essél neki. Ha a frontend a cél, akkor ne pazarold az időt a szerver oldalra. Ha kell, majd megtanulod, ha már felvettek. Nem valószínű, hogy kelleni fog, valszeg kapsz majd valami CRUD API-t, amihez GUI-t kell gyártanod asztali gépekhez, mobilra meg tabletre. Responsive web design még az a témakör, aminek érdemes utánajárnod. Ennél többet én sem nagyon tudok mondani a témáról, bár sok éve kliens oldali js-el kezdtem, mára már szívből gyűlölöm, és örülök, ha nem kell ilyesmivel foglalkoznom. Ellenben nodejs-t imádom. :-)