starboard

Forum - Vetercek.com

Tema: Vprašanje za web developerje (javascript vs PHP)

jaka87    [ 4 year ago]

Zdravo.

Kot verjetno veste je stran napisana v PHP. No kolega me je pred kratkim nahajpal (OK, tudi sam sem nekaj razmišljal) da bi naredil statično html stran + rest API in javascript da zafila podatke. To pomeni, da bi manj obremenil server, ker bi gor lavfal praktično samo rest service in v teoriji bi se stran tako tudi hitreje naložila, porabil pa bi manj podatkov.


Najprej sem razmišljal o uporabi raznih knjižnic, ala React, Vue... No nobene od teh nisem uporabljal, tudi v javascriptu nisem najbolj vešč tako da bi se moral naučiti. Potem sem prišel do spoznanja, da čist za vsak drek pa res ni treba svoj library in da bi to šlo kamot tudi z vanilla javascriptom...


No potem pa že nastane dilema. Če bi recimo imel nekaj miljonov obiska na dan pomojem niti nebi razmišljal o tem, tako pa trenutno (sploh po zadnji optimizaciji) resourcov definitivno ne primanjkuje in server deluje nekje na 30-40% in ni težav. Stran se hitro nalaga, ampak nikjer ne piše da nebi mogl bit še boljš. Za hec sem naredil dve podobni strani eno v PH drugo v javascriptu in primerjal velikost in hitrost nalaganja


javascript https://vetercek.com/nov/index.html

PHP https://vetercek.com/nov/index2.php


Sama velikost strani gre minimalno v prid javascriptu 5.4kb proti 5.1kb

tudi kar se tiče nalaganja strani se javascript nekoliko bolje izkaže 300 proti 500ms vendar pa če primerjam uporabniško izkušnjo bi rekel, da je občutek ravno obraten in da se PHP naloži bolj gladko. Še bolj se zakomplicira recimo na mobilnikih, ki predstavljajo več kot 50% vseh obiskovalcev. Tukaj je že vprašanje ali samo pocesiranje podatkov raje pustiti na strežiku ali pa na samem uporabniku. Tukaj imam občutek da je razlika skoraj še večja v prid PHP.


Če že, bi zaenkart na novo spisal samo prvo stran ter morda še dnevne podatke ostalo (še) ne. Zanimajo me vaša mnenja na to temo. Karkoli bo v pomoč...

Rekreator    [ 4 year ago]

Kot končni uporabnik ne opazim, da bi se vetrček kaj obotavljal pri nalaganju. Če imaš voljo se le nauči javascripta. Saj veš več kot znaš, več veljaš. :) 

jaka87    [ 4 year ago]

Ja saj nisem rekel, da počasi dela. Prej bi rekel, da dela dobro, če že ne odlično, zagotovo pa hitreje od povprečja. Seveda nikjer ne piše, da ne more bit še boljš... Kake posebne volje nimam, tud časa ni tako veliko, ampak če bi se res splačalo, bi ščasoma že nekaj spacal skupi.


V teoriji se sicer sliši kot no-brainer, da je javascript way to go. V praksi nisem več tako ziher, ker če ti mora procesorsko delo opraviti telefon je to lahko (tudi) počasneje od serverja... Ravno zato sprašujem, če mamo kakega mojstra za te stvari, da pove svoje mnenje...

slashrsm    [ 4 year ago]

Frontend appi (React, Vue) so zanimivi ko želiš narediti stran bolj interaktivno, bolj kot v smislu aplikacije (primer bi bil Gmail). Če tega ne potrebuješ je po mojem mnjenu težko upravičiti pristop s frontend appom. Seveda je lahko tudi želja po učenju nečesa novega čisto dober razlog. Osebno ti nebi priporočal pisat frontend app-a z vanilla JS. Če se boš odločil za to uporabi enega od frameworkov. Meni osebno je bil Vue všeč, pa tudi Elm se mi zdi kar zanimiv (ima sicer malo bolj alternativen pristop).

JavaScript app sam po sebi ti ne zagotavlja da bo stran delovala hitreje. a) še vedno boš delal klice na strežnik, tako da se bo njegovo počasnejše delovanje še vedno poznalo. Res da nekoliko manj opazno, pa vseeno. b) JavaScript app se da zelo hitro zakomplicirati do te mere da je počasen za umret. Uporaba JavaScripta ti sama po sebi ne zagotavlja odzivnosti. Pomembno je kako boš app spisal!

Moje mnenje je, da Veterček nima težav s performance-om. Pa tudi če bi jih imel se ponavadi vedno da lažje optimizirat obstoječ app kot pisati novega. 

Še ena zanimiva opcija bi lahko bil Phoenix z LiveView, ki temelji na Elixirju (ki zna bit sam po sebi precej hiter). Je pa res da gre za precej nišno zadevo.

https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript

https://www.phoenixframework.org/blog/build-a-real-time-twitter-clone-in-15-minutes-with-live-view-and-phoenix-1-5

jaka87    [ 4 year ago]

Hvala za odgovor. To sem iskal. 

Najprej sem res gledal bolj popularne knjižnice kot React in Vue, sploh Vue me je takoj pritegnila, potem sem gledal en zanimiv video na youtubu, kako folk za vsak drek uporablja frameworke in kako je lahko javascript tudi hitro preveč kompliciran. Potem sem naletel na Mithril, ki se mi je zdela zelo zanimiva opcija, ki bi jo najbrž tudi uporabil. Potem sem že začel razmišljat da v bistvu ne rabim kaj dosti in sem naredil zgornji primer v plain javascriptu. 


Sem pa potem razmišljal, da je treba naredit še avtentikacijo, lokalizacijo, in še en kup enih stvari tako da zaenkrat opuščam idejo, še posebej ker pri mojih primerih ni kakšne strašne razlike v preformansu.


Vsekakor pa bom obstoječ pejđ še mal spimpal. predvsem pri MySQL sem (bil) zelo švoh in sem naredil kak request več kot bi bilo treba, tako da seadj malo bolj pazim in jih joinam ko se da.

slashrsm    [ 4 year ago]

Pri poizvedbah v bazo ti lahko veliko pomagajo tudi indexi. Če jih pravilno postaviš ti lahko neverjetno pohitrijo zadeve, sploh če se gre za tabele z veliko vrsticami. Še en trik, ki sem ga jaz velikokrat uporabil je to, da poizkušaš s pogoji čim bolj zmanjšati dataset, tako da baza potem kakšne dodatne pogoje in sorte dela na čim manj vrsticah.

Primer: imaš nek seznam člankov ki so najbolj branih člankov. Če upališ query na celi bazi in nato sortiraš po ogledih zna to trajat kar dolgo časa. Če imaš v bazi članke za nekaj let nazaj lahko skleneš da boš iskal samo za zadnjih M tednov. Daš datum kot prvi pogoj, po možnosti podprtega z indexom in tako boš sortiral vnose zadnjih M tednov namesto za celotno zgodovino.

Tudi joini ti lahko upočasnijo določene poizvedbe (spet odvisno za kakšne podatke gre, kakšne indekse imaš, ...). Včasih zna bit hitreje narest več poizvedb v posamezne tabele. Pomembno je da takšne reči izmeriš (s cache-om izklopljenim: "SELECT SQL_NO_CACHE a,b,c FROM...").

thejan    [ 4 year ago]

Pridružujem se mnenju, da je PHP primeren za to kar dela in da vetercek.com deluje odlično hitro in se s stem sploh ne bi ubadal.

Raje še kako postajo postavit :)

Kot je slashrsm napisal je v tem primeru verjetno večina na bazi, to si tudi sam že pogruntal in optimiraš querye.

Javascript je res bolj za 'web appe', za pedenat GUI ipd.

Jaz se z bazami poklicno ukvarjam nekih 10 let, videl sem že vse živo, vsak SQL ima neke specifike in v grobem delujejo po podobnem principu.

Kar me je v zadnjih letih še najbolj pritegnilo je bil Influx kot namenska baza za časovne meritve, kar vetercek v bistvu je. Zelo dobro zadeva deluje, recimo v kombinaciji, ko imaš recimo podatke o 'entitetah', npr imena postaj, njihove koordinate, državo ipd. v MySQL, medtem ko vse meritve pišeš v Influx, kolonami ID postaje, tip meritve, npr. hitrost vetra, čas in vrednost.

Ker je Influx prav za to narejen impresivno hitro beležin in vrača take časovne podatke, npr. v JSON-u, naprej pa join narediš na MySQL in daš dataset PHPju v predstavitev... Mogoče, če hočeš na hitrosti delat je tudi v to smer za razmislit, kot rečeno pa hitro deluje in nekaj časa še zagotovo bo. Potem pa lahk tud brišeš podatke po nekaj letih verjetno...

Strani: 1   2   
Navodila

© jaka_87
Spletna stran uporablja piškotke z namenom, da vam ponudimo boljše uporabniške izkušnje, optimizacijo prikaza prilagojenih vsebin in spremljanje statistike obiska. Z nadaljevanjem obiska na spletni strani se strinjate z uporabo piškotkov.