2022-es frontend html/css/js/framework szabvány javaslatok és trend

Internet: PHP, CGI, stb.

Helló

Kimásztam a hibernáló kamrából, felébredtem, lemaradtam. Tíz éve meg régebben is csinálgattam honlapokat mint fullstack fejlesztő Htmlben: Doctype volt eleinte Html4, aztán Xhtml, majd Html5 a végén, azaz Doctype Html már csak. Írtam sima Javascriptet form ellenőrzésre, üres-e a mező, submit gombot ne nyomja meg kétszer, satöbbi. Aztán sok mindent már Jquery használattal oldottam meg a végén, szerettem. Volt sok kész slider, player és már akkor volt mindenféle Javascript framework. Meg ott a Css. Mostanában hogy szokás, miben érdemes elkezdeni, milyen szabványok, bootstrap, satöbbi?

Hobbi projektnek indul, de ki tudja egyszer mi lesz belőle, fő az optimizmus. Ahol majd elakadok, ott megbízok valami szakit, vagy más lesz, de érteni szeretném, mi most a trendi és amit tudok én összekalapálom.

A: Melyik Javascript frameworköt javasoljátok használni? Vagy milyen Html/Css/Js alapokat? Bootstrap? Jó lenne, ha van sok példa kód, amik felhasználhatóak. Nem tiszta, mi most a folyamat. Nem tűnik jó ötletnek 2022-ben mindent nulláról megírni, inkább kész elemekből építkeznék, hogy haladjak, meg mert jobb legyen. Igények ilyesmik:

B: A lehető legtöbb böngészőben működjenek a funkciói, kompatibilis legyen, a lehetőségekhez képest. Persze nem elvárás, hogy menjen Ie6on már. Minél több szabvány böngészőben menjen hiba nélkül.

C: Azt olvastam felületesen, hogy már az Ms Edge is Chrome, Firefox meg eltűnőben, és sok a Chrome klón, meg ott az almás Safari és ennyi?

D: Sokáig legyen a szabvány/framework támogatott. Ne kelljen pár éven belül átállni egy újabbra, vagy ha át kell, akkor egyszerű legyen. Például ismerős pár éve panaszkodott, milyen szívás volt Angular Jsről átállni az újabb aktuális Anular verzióra, újra kellett írni sok mindent miatta, valamit meg inkább már nem is Anular új verziójában csinált, nem emlékszem, hogy miben. Nekem nem kell feltétlen framework, összeírom mik kellenek, a lényeg az lenne, hogy ne kelljen sokáig hozzányúlni, ha működik. Simán lehet, hogy az én igényeimnek nem is kell framework, de majd eldöntöd.

E: Jó lenne, ha mobilon böngészőben is jól működnének, kompatibilis lenne ha például Androidon Chrome böngészőben nézem. Nyilván a Css és egyéb módon megoldom, hogy a felbontás / dpi meg az egyéb jó legyen, reszponzív. Például a Twitter Bootstrapja ránézésre több is, mint ami kell:

https://getbootstrap.com/2.0.2/examples/fluid.html#

1: Van más, amit javasolnátok? Ez időtállónak tűnik? Az én nézetemben az AngularJS nem időtálló, mert már nem támogatott. Most van, aki még ebben kezdi a fejlesztést? Nem igazán?

A funkciók, amiket szeretnék megvalósítani:

2: Json formátumban valamilyen backend rest apival kommunikálni, úgy néz ki Python lesz, esetleg Php vagy más. Ez a backend vezérelné a frontendet, már ha nem statikus tartalmat rak ki. Ez most nem téma, csak a szabvány, hogy tudjak Jsont olvasni és írni.

3: Videólejátszás: Youtube vagy saját player általi videók indítása, megállítása. Mp4 lejátszó, ami vezérelhető, értem ez alatt, hogy ha vége a lejátszásnak, szóljon a backendnek jsonban, hogy véget ért a lejátszás. A Chrome böngésző által támogatott mp4 fájlt nem nehéz lejátszani jelenleg, de biztos vannak trükkök, amire figyelni kell?

4: Hanglejátszás: mp3 vagy ogg formátum lejátászása, megállítása. Vagy amit a böngészők támogatnak. Mit?

5: Képek váltása, cseréje, átmenet, valami slider. Régen volt valami Lightbox, amit használtam az jó volt. Most van jobb?

6: Mindezeket a Jsonból kapott infókból, Json feldolgozás.

7: Formok ellenőrzése, hibajelzés, ha nincs kitöltve egy kötelező mező, satöbbi. Jqueryben könnyű volt, most mi a hasonló?

Ezt szeretném. Ha jól sejtem most is készülhetne Html5 + Jquery felhasználással ez az egész, de csak van ennél jobb?

Tudom, látom, néha még a 15 éves vagy régebbi oldalak is ott vannak módosítás nélkül a neten, az én régi fejlesztéseimnél is régebbiek. Jó lenne, ha ezeknél modernebbet tudnék összerakni.

Köszi a véleményeket.

( uTibor | 2022. 10. 05., sze – 07:15 )

Szerkesztve: 2022. 10. 05., sze – 07:15

Helló!

Ha most kellene egy új web + mobil projektet indítanom, akkor React vagy Flutter irányába indulnék el. A React elsősorban a népszerűsége miatt, pluszpont, hogy ha szükség van könnyebb mozdulni mobil irányba is React Native-val. A Fluttert nagyjából hasonló gondolatok mentén választanám, annyi pontosítással, hogy a Flutter viszonylag új versenyző a piacon, így teret adna egy kis kísérletezésre is.

Létjogosultsága lehet akár az Angular-nak is, vagy akár a sima HTML5 + jQuery kombinációnak, nem feltétlenül írnám le ezeket a technológiákat sem. Ha az utóbbi stackekből kellene választanom, akkor egyértelműen az Angular fele mennék, a jobb támogatás irányába. (Arra gondolok, hogy ha HTML5, jQuery vonalon jóval több mindent kellene saját magadnak megoldani, ami nehezíti a támogatást, ha valamiben elakadnál.)

( duffy v | 2022. 10. 05., sze – 08:37 )

HTML5+jQuery+Bootstrap aktuális.

Mindegyikhez jó dokumentáció van, így könnyen tanulható és a fenti igényeket abszolút lefedi. Továbbá nem különösebben nagy overhead/bloat a HTML-en...

HTML5, jQuery vonalon jóval több mindent kellene saját magadnak megoldani

Ezen segítene a Bootstrap. 

Egyetértek, jQuery ideje lejárt. Óriási segítség volt addig, amíg a bögészők nagy ívben tojtak a szabványra, ahány annyi féle. Ma már ez nem így van, alap javascript-el mindent meg lehet oldani kényelmesen és fog futni mindenen.

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

( covix v | 2022. 10. 05., sze – 09:12 )

Bootstrap 5 is designed to be used without jQuery, but it’s still possible to use our components with jQuery. If Bootstrap detects jQuery in the window object it’ll add all of our components in jQuery’s plugin system

 

jQuery szvsz kevés dolgot tud, amit vanilla JS-el ne lehetne megoldani.

KoviX

Nem-igen vannak érvek, mivel nem akarlak rábeszélni semmire. A véleményemet írtam a kérdésedre.

Amúgy meg a jQuery valóban semmi olyasmit nem tud, amit vanillával ne lehetne megoldani. Cserébe kicsit lassabb, mivel kb mindenből is objektumot csinál. Még az objektumokból is....

Ugyanakkor (nekem) a dokumentációja jobban kézre áll (meg csillom plugin van hozzá). Illetve, bár függhet a feladattól, de általában kevesebbet kell neked kódolni ugyanahhoz.

Szóval ez inkább ízlés kérdése bármilyen js megoldásra alkalmas mind a kettő.

UI-ra meg a bootstrapen kívül nem tudok kényelmesebbet.

Összefoglalom neked röviden:

A jQuery egy tök jó cucc volt 7 évvel ezelőtt. Kevesebb kódd írásával tudtál több munkát elvégezni dom traversing, animáció, ajax és hasonló területeken és minden böngészőben ugyanúgy futott a kód. Aztán jött 2015-ben az ES6 és később a még újabb, jobb verziók és a jQuery használata teljesen okafogyottá vált. Vanilla (azaz a "csupasz") js-el megoldhatsz mindent kényelmesen és sokkal jobb teljesítménnyel (a vanilla js akár 20-szor is gyorsabb lehet bizonyos feladatoknál, mint a jQuery).

Manapság pedig már szokszor nem sima HTML + CSS oldalakat gyártunk, amibe beletuszakolunk helyenként js-t, hogy dinamikus legyen, hanem úgynevezett SPA-kat, ami a single page application rövidítése. Nincs oldal újratöltés, amikor a user ráklikkel egy linkre. Nem kell ugyanazt a frontend elemet letölteni minden oldalváltáskor, nem terheljük a backendet rendereléssel, hanem a frontend framework megoldja ezeknek a kezelését a saját ökoszisztémájában a háttérben. A legismertebb ilyen frontend frameworkok a React, Vue, Angular.

Érdemes megismerkedni velük, teljesen újfajta szemléletet kapott ezeknek a létrehozásával a frontend világ. Nagyon hasznosak, ettől függetlenül persze nem muszáj minden weboldalon használni őket. Ha sok a dinamikus elem, sok a user interakció, akkor érdemes, de ha csak egy kis egyszerű frontendet igénylő projektet épít az ember, akkor oda elég a sima js. A jQuery-t pedig felejtsd el. Konkrétan láttam olyat, hogy valakit kiröhögtek interjún, mert megemlítette, hogy még 2022-ben is jQuery-t használ...

Why are Norwegians so good at editing files on Linux? Because their ancestors were vi-kings. ;)

Köszi az összefoglalót, ezeket nem tudtam. Megmagyaráztál sok mindent.

Akkor két fő irány van: single page application és sima js használat.

React esetén nem tiszta, ezekkel mi legyen mi nekem az ajánlott, ezt olvastam egy példa kód forrásában:
 

Note: this page is a great way to try React but it's not suitable for production.
      It slowly compiles JSX with Babel in the browser and uses a large development build of React.

      Read this section for a production-ready setup with JSX:
      https://reactjs.org/docs/add-react-to-a-website.html#add-jsx-to-a-project

      In a larger project, you can use an integrated toolchain that includes JSX instead:
      https://reactjs.org/docs/create-a-new-react-app.html

      You can also use React without JSX, in which case you can remove Babel:
      https://reactjs.org/docs/react-without-jsx.html

JSX legyen?

Vagy toolchain?

Babel hasznos nekem?

Azt javaslom, hogy ne a Reactal kezdj, hanem Vueval, mert tapasztalataim szerint azt sokkal egyszerűbb megérteni, sokkal könnyebb elkezdeni tényleges oldalakat összehozni benne, lévén, hogy nem annyira "opinionated", mint a React, vagy az Angular. Nem kell benne sem JSX-el, sem Typescriptel szenvedni, amik ugyan hasznosak tudnak lenni, viszont kezdéshez szerintem elég durván overkill.

Vueban simán külön tudod kezelni (egy fájlon belül) blokkokban a HTML-t, CSS-t és a JS kódot. Tanuláshoz javaslom Brad Traversy videó(it)ját: https://www.youtube.com/watch?v=qZXt1Aom3Cs

Why are Norwegians so good at editing files on Linux? Because their ancestors were vi-kings. ;)

A Typescript akkor hasznos, ha nagy projekten dolgozol, vagy többen dolgoztok rajta egyszerre, mert segít megtalálni a hibákat még fejlesztés közben. Erősen típusos nyelvekben, mint amilyenné a Typescript varázsolja a js-t könnyebb kideríteni, hogy mit akart a költő az adott kódrészlettel. Kis, vagy közepes projektekhez, ha egyedül dolgozol rajta szerintem nem érdemes használni, hacsak nem tanulni/gyakorolni szeretnél.

Why are Norwegians so good at editing files on Linux? Because their ancestors were vi-kings. ;)

Ez való igaz, viszont olyankor érdemes refactorálni a projektet. Nem érdemes egy olyan projektet, amiről az ember nem tudhatja, hogy befog-e futni, egyáltalán befejezi-e túltervezni (over engineering), mert minden újabb tool bonyolítani fogja a benne való munkát.

Egy egyszerű applikációt meglehet úgy is írni, hogy az ember react-ot, typescript-et, tailwind-et, sass-et, postcss-t, webpack-et használ a frontendhez, majd redish, node, nest, orm jön a backendhez és az egészet saját maga által konfigurált aws szervereken futtatja docker konténerekben, csak mire ezeket mindet összerakja és ténylegesen elkezd benne dolgozni megőszül.

Ehelyett sokkal jobban járna, ha frontendre bootstrap-et, petite-vue-t használna, a backendre pedig firebase-t és máris negyed annyi idő alatt tudja elérni ugyanazt a funkcionalitást. Ha pedig beindul a dolog, elkezdik használni az emberek, akkor újra lehet tervezni, hozzá lehet tenni, ami kell ahhoz, hogy a cucc tudjon skálázódni és bonyolultabb dolgokat jobban elvégezni.

Why are Norwegians so good at editing files on Linux? Because their ancestors were vi-kings. ;)

Nem írtam, hogy mindenre SPA-t kell használni, sőt, ami azt illeti épp az ellenkezőjét javasoltam:

Ha sok a dinamikus elem, sok a user interakció, akkor érdemes, de ha csak egy kis egyszerű frontendet igénylő projektet épít az ember, akkor oda elég a sima js.

Why are Norwegians so good at editing files on Linux? Because their ancestors were vi-kings. ;)

JS lib/framework mar nem a bongeszokompatibiliashoz kell. Az ugy IE10 es ES6 ota out of the box.

Mostmar azert kell a JS framework, hogy ne kezzel kelljen 8-10 display: none; / display: barmimas;-t toggle-ozni gombnyomasonkent harom callbackes foreachekben. Meg hasonlo logikaval 3 CSS class-t elvenni es masik 5 CSS class-t meg data attributumokat hozzaadni aztan change-t triggerelni.

Ujabban a frontend JS frameworkok elsodleges feladata ezt a terhet levenni a valladrol, de az ara megerteni, hogy miert jo Single Page App-ban es komponensekben gondolkodni.

( carlcolt | 2022. 10. 05., sze – 09:34 )

Szerkesztve: 2022. 10. 05., sze – 09:38

Vegul majdnem mindenbol React lett, abbol is, ami nem annak indult.

Legalabb gondolkodasmod szintjeig tanuld meg. Olyan dolgon, ahol ertelmezheto a "single page app". Utana VanillaJS-ezhetsz is. Akar csomagkezelo nelkul is. De elotte ertsd, hogy miert nem akarsz Reactot vagy v3.0 ota kinosan React-szeruen viselkedo frameworkot hasznalni csomagkezelovel. Ertsd azt is, hogy akarsz-e grunt-gulp-webpack vonalat vagy nem. Ehhez ki kell probalni.

Egy biztos: szerveroldalon a PHP mehet a kukaba, a node mar "leperformalja". Szeresd meg a callback, async, await, independent worker fogalmakat a szerveroldalhoz.

Szerencsere az Angular is a kuka fele tart. Azt nem is ajanlom. Senkinek.

Szerver: ha nem tetszik a node gondolata Pythonozhatsz is (Django, Flask, etc.), de ott is baratkozz meg a tobbprocesszoros rendszerekkel.

PHP-t mar tenyleg csak legacy webapp maintainelesehez erdemes hasznalni, ami nem er meg egy ujrairast. Arra viszont tovabbra is jo.

React esetében irgalmatlan mennyiségű anyag van a neten. Ha nekem kellene betanítani valakit, akkor alapvetően az alábbiakkal indítanám el (én ezeket találtam korábban magamnak, amik megfelelő minőségűek):

Ezek nagyrészt nem klasszikus oktatóanyagok, de egyrészt olvasmányosak, másrészt véleményem szerint a felsorolás sorrendjében átolvasgatva, közben kipróbálgatva a dolgokat eléggé jól el lehet benne mélyedni. :)

Szerk.: a nyitó posztban felvetett dolgokra néhány lehetséges megoldás Reacthoz kapcsolódóan:

  • 2 (JSON): ha csak nagyon egyszerű megoldás kell, akkor nagyon egyszerűen be lehet drótozni az alap fetch() és JSON.parse() metódusokat, bár fetch esetén utóbbi nem is kell feltétlenül, mert a Response is támogatja a JSON-be parse-olást. Ha valami komolyabb API-t szeretnél elérni, arra már kismillió library és framework van (divatos kulcsszavak mostanában az OpenAPI és a Swagger, de ez nem React- v. JS-specifikus).
    Szóval ehhez nem igazán kell React, de az alá is van több lib is, ami még a "ragasztókódot" is megspórolja vagy ad valami absztrakciót.
  • 3 (Videó): én eddig a projektjeimben a Video.js-t használtam (React-integrációhoz példák). Nem mondom, hogy nem volt néha fejvakarós, debuggolós feladatom, de végül mindent meg tudtam vele oldani, amit akartam. (Egyszerűbb esetekben itt is elég a "vanilla js" meg a HTMLMediaElement API, ld. Video and Audio APIs, Video and audio content, HTMLMediaElement.)
  • 4 (Hang): dettó
  • 5 (Slideshow, carousel): mint égen a csillag, annyi ilyen van, random google kereséssel: 14 Top React Carousel Components [2022] :)
  • 6: ld. 2. pont
  • 7 (formok): pl. React Hook Form (nekem néha kicsit nyakatekertnek tűnt a logikája, de sokat tud, az kétségtelen, és az alap esetekre elég egyszerűen használható - itt amire érdemes nagyon odafigyelni, az a "controlled components vs. uncontrolled components" témakör, ld. Uncontrolled Components, What are Controlled and Uncontrolled Components in React JS? Which one to use?)

Mert mast nem lehet Typescriptben irni? Muszaj a fostos Angulart? Ha TypeScriptet szeretsz, akkor TypeScriptet szeress, ne Angulart.

Amugy az osszes Angular verzio szar. Az elso tervezesi hibait mar az Angular2 letezese es masmilyenre tervezettsege is igazolja. A tobbi kesobbi mar kompatibilisebb az Angular2-vel, de erezhetoen eltuntek azok is egy evjarat utan az uj projektekbol, mar csak a meglevoket maintaineli a tobbseg.

Még mindig nem mondtad meg, hogy mi a konkrét baja az Angular2-nek. Én nem vagyok Web fejlesztő, ami kevés dinamikus oldalt csinálok, ott vanilla HTML+JS-t csináltam egy saját Java keretrendszerrel megspékelve, amivel szerverre tudok replikálni oda-vissza GUI elemeket. Ezzel meg tudok csinálni SPA-t is, ha kedvem tartja.

Az Angular 2-t kipróbáltam egyszer és nem találtam kifogásolni valót rajta, de ugye nem sokat tekertem tényleg csak kipróbáltam. Ezért kérdezem a hozzáértőbbeket. Azt gondolom, hogy ha egyszer szembe jönne olyan projekt, aminél fontos, hogy a szerver kímélve legyen, akkor ilyen teljesen kliens oldali appot csinálnék, ami akár Angular2 is lehetett volna. Az elv, hogy JavaScript kód rakja össze dinamikusan az oldalakat, az tetszik. Az is tetszik, hogy template-tel lehet mindezt megcsinálni. A dinamikus elemek logikája egy kicsit túl komplex volt elsőre, de azért végül felfogtam valahogy.

A TypeScript nekem úgy tűnt, hogy bekonfolni nehéz (ezt megcsinálta az Angular2 példaprojekt), illetve ha van valami VanillaJS megoldásom, akkor azt átírni korrekt TypeScriptre nem volt triviális nekem. De már alig emlékszem, nem is láttam mindent teljesen át, csak kipróbáltam.

Ha már így benne vagytok, hogy ilyeneket csináltok, elmondanátok, a SPA féle dinamikus oldalt hogy cacheeli például a Cloudflare vagy más Cdn szolgáltató? Mintha olyat olvastam volna, hogy valami static renderinget kell ilyenkor alkalmazni, azt a kereső is látja és azt a Cloudflare is tudja kezelni.

Nekem nem áll össze, ha van egy SPA, amiben van login, majd belép a felhasználó, és nem töltődik újra az oldal, de látja a belépett felhasználóknak való tartalmat, a Cloudflare itt mit tud csinálni, gyorsítani? A logint nyilván a backend originnek kell elvégeznie, de azt honnan tudja a Cloudflare, hogy azt ne kezelje?

Mert SPA nélkül azt mondanám, hogy mondjuk a /member/ mappát a Cloudflare ne cacheelje, a design elemek meg máshol vannak, így meg van oldva.

Ugyanígy kérdés SPA esetén a session kezelés is, hogy lehet megoldani?

Vagy hogy lehet megoldani a belépett felhasználó session kezelését Cloudflare esetén, ha csak sima Js van, SPA nélkül?

Én csak intranetes oldalakat csináltam eddig, a Cloudflare-ről semmi fogalmam nincsen. De azt gondolom meg most kicsit ránéztem, hogy standard cache control-t kell beállítani, a mindenki által látható resource-okat tudod cache-eltetni a Cloudflare-rel.

Mondjuk Angular2-t elképzelve az egész oldal egy bazi nagy JS alkalmazás egybecsomagolva. Illetve minden belépési URL-re adhatunk egy pre-renderelt képet, amennyiben nincs belépve a user. Az alkalmazást és ezeket a pre-renderelt HTML-eket cache-eli a Cloudflare.

Amit belépés után lát a user, azt már JS-ből indított queryken keresztül dumálják le (főleg WebSocket, de lehet GET POST stb is), amit pedig úgy állítunk be, hogy ne legyen cache-elhető.

( tomsolo | 2022. 10. 05., sze – 20:14 )

ha már js framework én mostanában svelte-zek inkább, nagyon jó a tutorial része, kb egy óra alatt átlátható és egy csomó dologra nem vagy rákényszerítve, ha static app akkor webpackkal mindegy mivel szolgálod ki

cssnél meg bulma-t szoktam használni, ez nem annyira bloated mint a többi, tény hogy nincs annyi komponense de az esetek nagy részében még  ez is sok

ha pont az ellentéte kell akkor ott a tailwind.css bár meggyőződésem, hogy használói nagy része tök fogalmatlanul paraméterezik, bár ez a bootstraposokra is igaz volt mindig

No rainbow, no sugar

> +svelte

 

biztos jo cucc lehet, bar a weboldaluk nekem hibat dob:

500: invalid identity escape in regular expression

 

Gondolom ez is rendesen ki van tesztelve chrome alatt, es csakis chrome alatt. Megnyugtato.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Most megneztem mindkettot, mobilon is es desktopon is. Ugyanugy hibat dob. A legalja. Tipikus macos hipszter fejlesztok altal taknyolt valami. Innen mar nagyon nehez velemenyt valtoztatni.

 

chromemal persze megy. Amugyis szepen betoltodik *minden* majd egy 2 masodperces hatasszunet utan atvalt a hibauzenet oldalra.

Ez frankon az igenytelenebb fejlesztoi magatartas.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Köszi, nem hallottam a svetléről, sem bulmáról sem tailwindről.

Nincs olyan, ahol a CSS is a csomag, koncepció része? Vagy azokat nem javasoljátok?

Például gondolkozom rajta, hogy egy hierarchiakelés adminját hogy valósítsam meg ezekkel az új eszközökkel.

A tipikus funkciók: ha valami alatt van valami elem, akkor nem törölhető, egy elem alatt bármennyi lehet, áthelyezhető, satöbbi. Sorba rendezés különböző paraméter vagy szám alapján.

Az elemnek meg feljönnek a tulajdonságai, ami meg egyedi, egyszerű form submit a módosítás és ha változott valami az adatbázishoz képest, akkor azt frissítem.

A régimódi rész, hogy a backend küldi el statikusan, majd ha mozgatni akarom, akkor az adott elemre kattinva kell kiválasztani, hova kerüljön. Azonban ha lenne több tízezer elem, és azt mindig feldolgozni, összehasonlítani, na ezt nem tudom, hogy miként kezelik az új csodák.

hát ööö...

milyen koncepciónak legyen a része a css, a css frameworkokon kívül? Nem kevered a frameworkot a CMS-el?

Jelenleg kb annyi a szerepük mint régen, behúzod és használod az osztályait a html részekben, ami meg kell még azt hozzá írod. Hál istennek 5 év alatt már fejlődtek annyit a böngik, hogy jó pár dolog triviális már - helyette van sok új ami meg nem ... hehe.

Az arbitary ordering nem frontend feladat hanem erősen backend, úgy biztos nem valósítanám meg ahogy te írtad szóval így elsőre nem látszik jónak a modell ha egy ilyen miatt az összeset kell frissíteni.

A régi jquery-s tudásodat úgy képzeld el a mostanihoz képest, hogy kb 10 éve az volt a divat, hogy kiköpött vmi htmlt a backend (pl. php) utána nekiálltál baszogatni az elemjeit(DOM) jqueryvel, hogy vhogy kinézzen meg működjön ahogy szeretnéd. Most meg előre megtudod mondani (Virtual DOM) mikor/mi jelenjen meg és mit csináljon sőt ha közben változnak az adatok a háttérben/szerveren akkor azt azonnal láthatod (SSR) vagy reagálhatnak rá a komponenseid. (Ezért is vált okafogyottá ITT a jquery mert ide nem kell már).

Például van egy űrlapod ahol checkboxxal lehet be jelölni melyik koncertre szeretnél elmenni, de mindegyiknek van egy határideje amíg lehet rá jelenkezni. Tegyük fel 4 koncert van amiből az egyiknek éjfékor lejár határideje, a user azaz te meg hajnali egy percig töprengett  a böngésző ablak előtt mi legyen. Na most régen beikszelted mind a 4-t utána visszadobta a backend hogy az egyik már nem jó. Most meg 00:00 kor egyszerűen eltűnik a választható lehetőségek közül (hehe, rémálom lenne UX szempontból) vagy feljön egy toast hogy már ide no-go és disabled lesz.

No rainbow, no sugar

Hát ööö jól összefoglaltad, tényleg ezek rémlenek, hogy így meg úgy kellett. Köszi.

Kb 5 éve beszélgettem Frontendesekkel a Client Side Renderingről, meg az Angulárról, és arra panaszkodtak, hogy volt olyan magyar cég, ahol ilyet fejlesztettek. Olyan lassú, kis teljesítményű, monitor mögé rakott olcsó régi gépen ment a frontend, hogy 1-1 kattintásra másodperceket kellett várni, vagy akár 10 másodperceket, pedig helyi hálózaton érte el a backendet a frontend, és ott vissza kellett állni a hagyományos szerver oldali működésre, mert az jóval gyorsabb volt.

Biztos kivétel volt ez a projekt, nem tudok részleteket, mi volt az oka ennek, hogy így alakult.

ilyen akkor van, ha tobb 10000 adatot kell megneznie hogy valtozott-e a modelben. pl. egy jo nagy tablazat megjelenitese eseten. ezt ugy lehet megoldani, hogy vagy felteszel egy lapozot, ahol kb. annyi sort teszel ki ami a kepernyore kifer, vagy egy virtualis gorgetot.

neked aztan fura humorod van...

Most már még jobban tudom, hogy milyen keveset tudok! :)

Néhány évvel ezelőtt egy hasonló ábra döbbentett rá engem is arra, hogy mennyire elment mellettem a frontendes világ (css, alap jquery megvolt, de kb. annyi). Eléggé elszégyelltem magam, úgyhogy elkezdtem kicsit erőltetni a témát a különböző projektjeimben (JS esetén rátaláltam a The Modern JavaScript Tutorial c. oldalra, illetve láttam, hogy az MDN-en mindenhez van részletes referencia doksi), és most már egészen profinak érzem magam. :)

Viszont azt is beláttam, hogy a "mindenhez egy kicsit értek" ezen a területen biztosan nem fog működni, mert akkora a kupac, amit meg kellene ismerni, hogy az lehetetlen (legalábbis úgy, hogy van mellette életed is). Viszont stabil alapokra építve (többiek által fejtegetett "vanilla js" ismerete szerintem is kulcsfontosságú, legalább a fentebb említett "modern tutorial" mélységéig) már kb. az ábra bármelyik "dobozkájához" ki lehet tanulni az alapokat viszonylag gyorsan.

Szerintem jó móka ez a frontendes terület (és meglehetősen látványos), csak mint minden fejlesztői tudás esetében, itt is sokat kell gyakorolni és hibázni...

Ja, és ma már nem az IE megfelelő támogatása a szívás, hanem a Safarié, meg a mobil böngészőké. :)

sokkal rosszabb, a szabvány: https://html.spec.whatwg.org/multipage/

Egyrészt ugye csodálatos a "Living Standard — Last Updated 7 October 2022", de nagyon javaslom megtekintésre az 1.1-es fejezetet. Kissé sokkhatás.

(rejtett sub)

( Dyl4n | 2023. 02. 12., v – 22:39 )

Laravel + livewire vonalat esetleg nézted?

(+sub)

( Carter | 2023. 02. 17., p – 14:25 )

Nem ülsz fordítva a lovon? A weboldalnak információt kell átadni. Még egy sor infót nem adtál át, de máris betöltött több megabájtnyi keretrendszer, framework, JS, kiskutyafüle. Bejött a több megás háttérkép, megjöttek a sprite-ok, kódrészletek, előre betöltött elemek.

Én először megcsinálnám a weboldalt, hogy funkcionálisan működjön, adja át az infót. Aztán lehet pár kbyte CSS-el szépíteni, de hogy becsicsázni, hogy csak a chrome-on menjen... ?

Egy régebbi mobilkészülékem van (iphone SE) már nem támogatott sehol. ingatlan.com, jószarfogás, google, gmail, bármit nézhetsz: használhatatlan. Minden egyes app, weboldal a kétszer-négyszer ekkora kijelzőre van optimalizálva.

A nyavajás netbankbank kihívás beírni egy számlaszámot-nevet, mert egyből szétcsúszik az egész, takarásba kerül a beviteli mező! Ez a szép új jövő, hogy minden legyen 10 megabájtnyi JS, vödörnyi adatbeviteli mezőkkel. Ha van mobil, akkor miért táblaméretre fejlesztenek? Hová lettünk?

Megöregedtem :D Elásom magam.