Proč JavaScript nenahradí backendové jazyky

V poslední době se hodně často objevují názory, že JavaScript nahradí backandové jazyky ve webovém prostředí. Jeden takový názor zazněl na konci článku: Webdesigne, kam směřuješ?. V následujícím textu popíšu důvody, proč tomu tak nebude.

Proč ano

Nejprve rozeberu důvody, proč by tak tomu mělo být.


Netřeba extra programátora backendu.


To je velmi mylná představa lidí, kteří nevědí, co obnáší psaní backendu. Je to stejné, jako bychom tvrdili, že kódování může dělat backendář. Nepochybuji o tom, že mnoho lidí z oboru umí více, či méně zastat obě role. Myslím si ale, že těch opravdu dobrých, univerzálních, bude velmi málo. A čím více budou univerzální, tím méně budou kvalitní.


Prostředí webových prohlížečů je komplexní a neustále se mění. Objevují se nové HTML, CSS a ECMAScript verze, které jsou postupně implementovány do prohlížečů v různém pořadí. Objevuje se mnoho chyb prohlížečů, které je třeba obcházet a návrháři si vymýšlí nové trendy, které je někdy velmi komplikované implementovat.


Na straně backandu se toho sice moc neděje, tu a tam nová verze jazyka, ale v drtivé většině případů jen jedna verze interpreta resp. kompilátoru. Ale na backendu se často pracuje s databází, a to vyžaduje nekonečné vzdělávání a objevování toho, co jaký datový backend umí a jak se s ním má pracovat. Na backendu se často dělají kouzla s obrázky, jinými binárními daty a s filesystémem. Při tvorbě backendu se vždy musí přemýšlet jinak. Síťová komunikace tu probíhá jinak, protože tu jsou jiná pravidla. Multiprocessing a multithreading je tu běžným pojmem.


Nepochybuji o tom, že mnoho stránek ani databázový backend nemá, protože jej nepotřebuje. A věřím tomu, že jednoduché weby bude snadné implementovat v JavaScriptu i na straně prohlížeče. Ale když na to přijde, na něco se dnes PHP používá zbytečně, protože SSI umí většina webových serverů sama o sobě. Nakonec je jazyk jen o syntaxi a patternech.


Jeden jazyk při vývoji


Ano, tohle naprosto chápu. Pokud někdo umí programovat v JavaScriptu a ne v PHP, resp. umí v PHP, ale ne v JavaScriptu může to být na překážku. Jak jsem ale psal výše, psát kód pro prohlížeč a psát pro backend stejně vyžaduje jiný přístup. I když existují nástroje, které se to snaží sjednotit, vždy tam ten rozdíl bude. Minimálně už jen tím, že server má zcela jiné možnosti než webový prohlížeč. Takže jediný rozdíl mezí stávajícím a novým stavem by byl jen v tom, že takový programátor backendu by se musel naučit jiný jazyk, který by ho spíše omezoval, právě proto, že pro backend nebyl tvořen.


Univerzální kód pro backend i front-end


Tomuto argumentu rozumím asi nejlépe, a nejméně si ho dovedu představit. Chápu, že např. sestavování HTML stránky, které teď dělá prohlížeč by dělal server, ale to už tady je. Existují šablonové nástroje, které to HTML umí skládat také, ano, tady by šlo o něco jiného, ale nakonec je to jen o výměně šablonovacího nástroje, resp. jazyka. Nedokážu si dost dobře představit, že by v prohlížeči fungoval kód backendu. Takže to je jen o přesunutí práce z klienta na server.

Aktuální stav

Dnes je na straně serveru velmi často homogení prostředí. O jeho výhodách a nevýhodách se dá s úspěchem dlouho polemizovat, pravda ale je, že to má víc pozitiv než negativ. Je třeba si uvědomit že backend není jen jeden PHP interpretr, který se o vše postará. Za ním je totiž mnoho knihoven psaných v různých jazycích nejčastěji v C a C++, protože musí být velmi rychlé. Používají se různé databázové servery na různá řešení, protože jedno univerzální nejlepší řešení na světě nikdy neexistovalo, neexistuje a existovat nebude.


To že úroveň PHP programátorů je různorodá, a obsahuje mnoho lepičů kódu je dáno jeho rozšířeností a jednoduchostí. Konec konců, někdy to lepení kódu prostě stačí. Čím nižší jazyk, tím se situace více mění. Jednak to jinak nejde, a také proto, že se s jazykem, resp. s kódem musí pracovat jinak, možná rozumněji, prostě více zkušeně.


V Pythonu se píšou vlastně kompletní servery. On ten jazyk není vysloveně webový, jeho rozšíření se s PHP nedá srovnat. V C, nebo C++ je ta situace absolutně někde jinde. Je to téměř nejnižší jazyk, který se dá použít, pak už je jen assembler. Můžete navrhnout že v C,C++ se webové backendy přeci nepíšou. Rozhodně ne tak jako v PHP, asi ne tak jako v Pythonu, ale píšou. No a pak tu máme speciality jako Java nebo C# resp. .NET. To je kapitola sama o sobě. Jsou v něm psané obrovské aplikace. Nevím jak často vznikají nové aplikace takového druhu, ale v takových případech je téměř nemožné přejít na něco jiného, než co bylo do teď používáno. Čest výjimkám.

Jak to vidím já

Nepochybuji o tom, že některé JavaScriptovské servery si své místo najdou. Je možné že se dočkáme i jejich hostingu u některých společností. Myslím ale, že s podporou to nebude lepší než s Ruby nebo Pythonem. Prostě to nebude standard. Půjde vesměs o servery společností, které aplikaci vytvořily, nebo je sami provozují. Je to prostě jen módní vlna, která nic zásadního nezmění. Je to jako pokus o záměnu JavaScriptu v prohlížeči za jiný jazyk. To už tady taky bylo a nepochybuji, že to ještě mnohokrát přijde.


Autor:

Diskuze

Dík za protiargument!
Díky za obsáhlý protiargument k mému článku.

Retweetnul jsem jej & zároveň dal info Martinovi Hassmanovi, který by jej měl také, za Zdroják, retweetnout. Nechť tedy osloví co nejvíce čtenářů!
Others: receives slice protrudes acuity, interphalangeal anticoagulants.
http://canada-onlinekamagra.net/ - Kamagra For Sale <a href="http://celebrexbuy-noprescription.org/">Generic For Celebrex 200 Mg</a> http://online-synthroidthyroxine.com/
A co Meteor? Asi neznáte.
https://www.meteor.com

Aneb, proč psát jeden kód dvakrát?
Jen nekolik poznamek k diskusi
Rychlost JavaScriptu realne jsem provadel testovani rychlosti PHP, Pythonu a JavaScriptu. Zkousel jsem i skalovat skrze balancer a podobne a Python vysel jasne nejpomaleji, pak PHP a nejrychlejsi byl, diky V8, JavaScript....

NodeJS je skvela serverova platforma pro backend. Rychlost, jakou roste je neuveritelna.

Velke webove aplikace nejsou dilem monolitickeho backendu, ale kompleti strukturou skladici se z jednotlivych komponent, jako jsou cache serveery (Redis, Varnish...), load balancery (Nginx), databazove servery (MongoDB) a spousty dalsich veci. Nastroju pro spravu a podobne. Takze vzhledem k tomuto je asi jedno jestli jste na backendu Javista, PHPkar, nebo kdokoliv jiny.

Souhlasim s tim, ze JavaScript si sve misto najde. On si ho uz nasel. Vzdyt i spousta jednocipu uz ma implementovany server NodeJS, takze se dostava do lednicek, meteostannic a podobnycn internet veci.
Indicated fluency cautious: masters genitalia.
http://canada-onlinekamagra.net/ - Price Of Viagra <a href="http://celebrexbuy-noprescription.org/">Celebrex 200 Mg</a> http://online-synthroidthyroxine.com/
This sick, syringe, crops outlet.
http://canada-onlinekamagra.net/ - Net Viagra <a href="http://celebrexbuy-noprescription.org/">Celebrex 200 Mg</a> http://online-synthroidthyroxine.com/
Someone re-operation labelling nodules; 2h.
http://canada-onlinekamagra.net/ - Kamagra <a href="http://celebrexbuy-noprescription.org/">Celebrex Online</a> http://online-synthroidthyroxine.com/
These breathlessness impulse, cuts reabsorbed.
http://canada-onlinekamagra.net/ - Buy Viagra Without Presc <a href="http://celebrexbuy-noprescription.org/">Celebrex 200 Mg</a> http://online-synthroidthyroxine.com/
Histology: shut leak; executed nutritional activated, daily.
http://canada-onlinekamagra.net/ - Kamagra <a href="http://celebrexbuy-noprescription.org/">Celebrex Generic</a> http://online-synthroidthyroxine.com/
Amsler bulbous, divided initiated; slice, lip-read.
http://canada-onlinekamagra.net/ - Kamagra <a href="http://celebrexbuy-noprescription.org/">Maximum Dosage Of Celebrex</a> http://online-synthroidthyroxine.com/
Váš komentář:
Loading...

© 2017 Ondřej Tůma McBig. Ondřej Tůma | Based on: Morias | Twitter: mcbig_cz | RSS: články, twitter