Daca PHP n-ar fi fost inventat

Limbaje de Programare
1

Daca PHP n-ar fi fost inventat, te-ai fi apucat de webdev la finalul anilor '90/inceputul anilor 2000 folosind:

  • C si/sau C++
  • Perl
  • Python
  • Ruby
  • Java
  • ASP
  • ColdFusion
  • Nu m-as fi apucat de web dev

0 participanți

2

Am folosit Perl, ASP (cu javascript) și Java (JSP) înainte de PHP (pe care l-am abandonat relativ repede)…

Also, C/C++ pt webdev, really?

3

Java era destul de avansat la vremea aia (J2EE, Servelt). Daca mai asteptai vreo 2-3 ani aparea si Spring
ASP era un fel de Visual Basic pus intr-o pagina wev
C/C++ prea greu
Ruby si Python nu cred ca aveau un ceva pe web (framework and related), dar cred ca se puteau face programe care expuneau ceva pe http.
Iar de Cold Fusion nu am auzit pe aici.

Interesant este ca pe atunci a aparut C# si peste vreo 2 ani asp net

4

Really. Backendul la care lucrez eu e in proportie covarsitoare C++. Si expune si web. Face si multe alte chestii, dar e si backend de-ala stil ‘web’.

5

Mie c++ plus backend Web mi se pare o invitație la buffer overflow :joy:

1 Like
6

Inseamna ca te invita foarte multe web servere si ce-i legat de ele :slight_smile:

7

Ruby on Rails dacă aveam Mac.

Perl/Python pe Linux.

C# pe Windows.

Cel mai tare pe front-end în trecut era ActionScript-ul din Flash, nici nu se pune problema de altceva. Pe Linux/Mac nu era bine suportat.

8

Rails a aparut destul de tarziu, abia in 2004.

9

Pt ca descarca bateria. Trebuie sa multimim Apple pt insistenta de a refuza Flash, ca altfel era trist peisajul web dev.

2 Likes
10

Motivul nr. 1 pentru care flash era pe val era că prezenta o soluție excelentă prin care te asigurai că lucrurile arată similar pe orice browser.

Dar spre sfârșitul anilor 2000 oricum se începuse să se bată monedă pe modul în care browserele respectă/interpretează standardele html/css/js: Chrome era proaspăt lansat, Firefox era pe val, cota de piață a IE era în cădere liberă. Odată cu lansarea iphone (și mai apoi ipad) a revenit[1] responsive la modă, care prezenta o problemă serioasă pentru flash. Apoi mai era și problema cu touch: pe Android erau browsere cu suport de flash (ba chiar și în app store sau cydia), dar experiența utilizatorului era groaznică.

Decizia Apple de a nu suporta Flash a ajutat la dispariția mai rapidă[2]. Cu siguranță ar fi fost abandonat indiferent de decizia Apple, dar probabil s-ar mai fi târât vreo cinci ani.

Și ca să răspund întrebării inițiale: probabil m-aș fi chinuit cu Perl, cu care începusem înainte să descopăr PHP. :smiley:

  1. pentru cei mai tineri, prin '98-'99 când am început eu să citesc despre HTML, se menționa peste tot că „holy grail-ul” web designului este «fluid design», adică să faci pe dracu’n patru ca site-ul să arate decent pe orice rezoluție. Responsive design - reinventat la sfârșitul anilor 2000 - este doar un hype făcut să pară mega-original. ↩︎

  2. chiar și-așa, tot au fost necesari ~5 ani să dispară vizibil și ~10 să dispară definitiv ↩︎

11

Primul meu job a fost de php /java coder in 2004.
Am trecut un test de Java destul de basic și m-au întrebat în trecere de php.

Dupa 1 an s-a demonstrat ca era de php și orice mai trebuie prin firma(condus masina, asamblat și carat servere, testare).
Ocazie cu care am scris php, am scris c++ și perl dar nicio linie de Java.

Si php4 care este practic ancient history.
Dar are un mare avantaj : feedback instant.
Fara timp pierdut cu compilare și deploy, editam direct pe server în caz de urgenta.
Editam direct în vim/mc pe vremea aia (toti aveam linux gentoo și nici nu se discuta de altceva).

Ce vremuri…

As mai scrie php?

Nu spun niciodată niciodată, pentru diverse aplicații e încă util.

Totusi am făcut un efort și mi-am dublat salariul în lumea Java.

Desi m-am jucat cu Scala și Kotlin și Ruby on Rails, python si putin Haskell nu am ieșit din lumea Java.

It paid for my retirement.

12

C probabil nu ar fi o idee prea bună, din cauză că trebuie să faci manual managementul memoriei și ești obligat să lucrezi cu raw pointers, dar C++… Dacă ar exista ceva similar flask/jinja pentru C++ aș trece instant pe el.

Chiar o să arunc o privire mai atentă la Jinja2Cpp.

13

Descoperisem mai demult CppCMS — High Performance C++ Web Framework. Ulterior au introdus in boost suport pentru HTTP(S) (client si server) Chapter 1. Boost.Beast - 1.78.0

Depinde si ce nevoie ai. Azi de exemplu poate nu mai vrei deloc templates pe server si te multumesti sa raspunzi doar JSON la API calls, ceea ce simplifica si mai mult treaba.

14

Fun fact: Rasmus a inventat PHP tocmai că nu-i plăcea să scrie C :smiley: (a zis printr-o prezentare acum câțiva ani)

15

De Go nu zice nimeni in loc de C++ pentru aplicatii web?
:stuck_out_tongue:

16

Erau şi alte timpuri, la vremea aia probabil singura posibilitate de a scrie aplicaţii web în C era s-o faci cu cgi, libcgi era abia la început (nici nu ştiu dacă exista la vremea când a început dezvoltarea php-ului). Era şi foarte dificil de utilizat, m-am jucat cu el o perioadă. Nu existau nici biblioteci ajutătoare, nu exista conceptul de “framework” etc.

FastCGI era şi el în primele zile de viaţă, probabil era un chin pentru cei care aveau site-uri mari, deoarece cgi spawnează ditamai procesul pentru fiecare request…

1 Like
17

Sure. De fapt nici măcar nu e nevoie de un webserver dacă nu partajezi mai multe website-uri, poţi să foloseşti direct o bibliotecă gen mongoose şi serveşti doar JSON şi fişiere statice, iar pe frontend să foloseşti Angular/React/Vue/Svelte/whatever (chiar şi jsrender sau js chior ar putea fi suficient în unele cazuri).

Dar nu sunt foarte sigur ce părere are Google de implementările cu randările făcute pe client. Ştiu că ştie să parseze şi paginile generate cu js, dar nu există penalizari din punct de vedere SEO? N-am avut curaj să testez :slight_smile:

18

CGI practic inseamna ca ce scrii cu printf() ajunge la client, inputul de la client il citesti cu scanf() (request body) iar headerele le primesti in env. E simplu in ideea in care n-ai nevoie de alte biblioteci pentru a interactiona cu serverul, indiferent de limbajul folosit.

Metode alternative la vremea aceea de a servi HTTP din C includeau module pentru a incarca aplicatia direct in server sau chiar un server custom.

19

C/C++ e absolut oribil de utilizat chiar si in ziua de azi. (cu mici exceptii)

E un chin sa schimbi versiunile de compilator, daca ai noroc fiecare librarie specifica clar ce versiune iti trebuie pentru MSVC, g++… Dupa distreaza-te pana nimeresti compilatorul cu librariile. (si e o arta sa tii mai multe compilatoare deodata, la linux cum n-aveai virtualizare versiunea de g++ posibil era legata de multe altele din distro, deci iti trebuie alta instalatie de linux doar sa schimbi compilatorul altfel riscai sa strici tot)
DLL-urile daca le descarci random de pe net risti sa fie cu keyloggere, backdoor, virusi. La php ai tot codul vizibil, posibil obfuscat dar e clar un red flag pentru un shell.

Nici php n-avea un package manager, deci nu o sa ma leg de asta. Dar luai un fisier de php si aia era libraria, la C/C++ luai o librarie, un dll si aveai niste instructiuni in text.

Dar o sa ma leg foarte tare de build cu C/C++, chiar si in 2022 daca iei 80% din proiecte de pe github jumatate de zi stai sa inveti cum faci build la proiect si toate dependintele lui. Daca ai noroc iti si merge dupa. Trebuie sa schimbi o librarie, hopa se plange de compilator.

Un programator de C/C++ pe Windows cred ca are instalat fiecare Visual Studio din 2008 pana in 2022. Carmack zicea intr-un tweet ca are cate un calculator pus deoparte pentru fiecare proiect ca nu crede ca mai reuseste sa faca build la cod.

In anii 2000 era si mai complicat ca era faza cu NT si DOS, pe NT aveai api-urile de NT si pe dos n-aveai nimic, trebuiau dll-uri pe care le luai de pe site-uri fantoma.

20

Sub Linux e mai simplu. Daca te multumesti cu compilatorul default poate fi as easy as apt-get install libcutare-dev