0djek

gal koks encoding pasikeite?

paprastesnis tai gal va kai ne daug endpoint'u, bet kai prisides daug daugiau visokiu papildomu detaliu sone (auth, middlewares, etc), tada ir bedos prasides. As pavydziui naudoju ASP.Net core framework'a API kurti, tai jis man issprendzia tokius dalykus: Middlewares Dependency injection Swagger docs Authentication Authorization Auto request and response parsing Tikrai tikiu kad dar daugiau yra, kurios nuo manes pasleptos Jeigu kalba turi ORM, kuri patogu naudoti: why not. C# man rodos patogaus by default neturi, tai kazka naudoti tenka. ORM pa

Jeigu sugebi ant tiek blogai pasinaudoti framework'u, kad visur darbas stoja: cia jau ne template'o problema. Plius dauguma framework'u yra tikrai geriau optimizuoti, negu kad galetum rankomis pasidaryti. Arba naudoji toki framework'a, kuris jau letas yra ir visi skundziasi, kad letas yra. Nori pasakyt, kad jeigu darysi API, kur yra 2 endpoint'ai ir lieps daryti tau su Python pvz, pats ranka rasyti socketus, juos priziuresi, paskirstysi pagal uzklausos URL i teisingus metodus ir pns? Nes naudojant koki Flask arba FastAPI butu per "leta" bei "uzkrausi serveri"? Ka darysi, kai reikes ta API

Kurioj vietoj pas jį kas blogai? Nelabai supratau, dėl ko ji puoli, kai jis tiesa sako 😄 ir priciom čia klientų ir serverio gaila? Paaiškino biski

Tai čia jau ne frameworko kaltę, o pačio programerio. Mikrokontrelius pvz programuojant irgi gali naudoti abstrakcijas, tačiau jeigu reikia greičio, tikslumo ar dar kažko, ko negali pasiekti naudojant abstrakcijas, tada tenka dirbti be jų. VSCode frontend'as su plain JavaScript (arba typescript, nlb pamenu) padarytas, nes jiems greičio reikėjo ir tikslumo. Patys pasidarydami FE framework'a, jie valdo, kaip elementus sukuria, kada juos sukuria, patys gali susitvarkyti bug'us vietoj to, kad laukti, kol kažkas kitas tą padarys. Dėl to daug kas ir pataria pasimokyti, kelis paprastus projektus

del sql'o: ka darysi, kai (kaip pries tai minejo), dirbsi su viena DB, o paskui ja pakeisti turesi? Begsi per visus SQL ir ranka kaitaliosi? Ka daryti, jeigu projektas didelis? Kiek laiko sugaisi tam? Naudojant lib'a tam, vienintelis tavo pakeitimas butu prisijungimo pakeitimas (yra atvejais, kai koks DB kazko nepalaiko, ka kitas palaiko, bet pakankamai retas). O kai nauja projekta kuri, ar neimi is seno projekto nieko? Viska nuo 0 darai? Daugiau:

Papildant @gabber, jeigu girdejes apie StackOverflow, tai jis naudojant .Net padarytas (source: https://en.wikipedia.org/wiki/Stack_Overflow#Technology). Jeigu butu kure viska nuo 0, jiems butu reikeje patiems pasidaryti: autentifikacijos flow autorizacijos flow kontrolerius (i koki url kreipiantis, kas turetu ivykti) middlewares infrastructure SQL rasymas ir priziurejimas (daug patogiau dirbti su SQL, kai gauni type safety) HTML generator dar daug kas Gali but, kad paklydau vietomis, tai del to sorry (gal kazkas istaisys, irgi nesupyksiu)

Jeigu tik php, tai pagrinde ir bus server side rendering. Kaip sakei gali naudoti php per wasm ir gauti client side rendering, bet ar nebūtų tada paprasčiau naudoti tinkamą įrankį darbui (tiesiog JavaScript)? Dėl dinamiškumo: kaip paaiskintum tada dinamiškumą ir universaliskuma?

Už JavaScript php mažiau dinaminis, nes jau ką jis atidavė į naršykle: nebepakeis. Be JavaScript patogiai nepadarysi, kad paspaudus mygtuką, keli papildomai formos laukai atsiranda. Pametem tema: kuom blogai apsišvietęs buvau, kad php client side rendering yra?

Bet ar php client side rendering atliks? :D nelabai, dėl to ir sakau, kad php client side rendering nepadarysi :D O su kuo tu tuos duomenis paduosi I naršyklė skirtumo nėra, nes renderins juos vistiek jau javascript

jeigu Php naudoji, labai abejoju kad client side rendering gausi. Php juk server sided language yra 😄