Afbeeldingsbron: pixabay.com

Dus, voordat ik hier een koude oorlog begin, tussen mensen die Rails (Ruby) gebruiken en PHP, wil ik je zeggen dat ik hier niet ben om te debatteren of welke taal beter is. Voor mij, of voor elke ervaren programmeur, zou hetzelfde zijn. Het is gewoon een kwestie van waarschijnlijkheid wie de voorkeur geeft aan wat en wat gemakkelijk voor hen is.

In deze blog zou ik het vooral hebben over het belang van beiden en hoe ze van elkaar verschillen. Dus, als je nieuw bent bij Rails en PHP beiden, dan zou dit de perfecte blog voor je kunnen zijn, als je er één uit een van de twee wilt selecteren. Dus laten we beginnen. Zullen we?

Enkele basisachtergrond

Om te beginnen is PHP een scripttaal, terwijl RAILS een framework voor webontwikkeling is, dat is gebaseerd op de scripttaal Ruby. PHP is een veelgebruikte programmeertaal voor websites zoals Facebook, WordPress, Yahoo, Flickr en nog veel meer. PHP is extreem snel, n keer stabieler dan Rails en heeft zelfs een grotere gemeenschap van ontwikkelaars om het te ondersteunen.

Rails is volledig gebaseerd op Ruby. Het is uiterst eenvoudig te gebruiken en aan de slag te gaan. Omgeving in Ruby is erg geautomatiseerd. Ruby is echt een vrij verbazingwekkende taal. In tegenstelling tot PHP is het echt Object Oriented van de grond af. De code is erg beknopt en krachtig. Met edelstenen (extensies) kunt u de benodigde functionaliteit gebruiken. Na codering in Ruby, vind ik codering in PHP nogal vervelend.

De goede de slechte en de lelijke

  1. PHP

Mijn advies is PHP, omdat het gebruik van PHP op het basisniveau heel eenvoudig is, er zijn veel mensen die weten wat sjablooncode te kopiëren / plakken, de configuratiebestanden te wijzigen en ze kunnen zichzelf zelfs PHP-programmeurs noemen, dat geeft PHP een zeer slechte naam die volgens mij niet verdient.

Voor een echte programmeur maakt het niet echt uit welke taal hij gebruikt, het is wat hij codeert en de manier waarop hij codeert die ertoe doet. Na het leren van enkele programmeertalen, begrijp je dat de meeste erg op elkaar lijken, het is meestal de syntax die anders is (vooral in hun kernmechanisme, zelfs voor een ander programmeerparadigma).

De eerste dingen die je moet leren is het schrijven van schone en leesbare code en niet om te geavanceerde code te schrijven, omdat het moeilijker te debuggen en verwarrend is voor iemand die de speciale trucs van de taal niet kent (met PHP kun je allerlei lastige dingen doen) dingen, niet alle zijn voor de hand liggend voor andere programmeurs).

In vergelijking met PHP is Rails ook onvriendelijk als het gaat om fouten. Met PHP spuugt het je uit tijdens de ontwikkeling en de foutmeldingen zijn logisch. Meestal wordt een pagina weergegeven, maar het gedeelte met de fout geeft aan welke regel de fout is opgetreden en het bericht nuttig is. In Rails blaast meestal de hele app op.

Het spijt me dat ik sommige mensen hier beledig, maar Ruby is gewoon niet zo eenvoudig als PHP om te leren. Het is in alle opzichten een extreem krachtige taal. Ik kies ervoor om Ruby te gebruiken, simpelweg omdat ik als ontwikkelaar het gevoel heb dat het een veel betere taal is dan PHP. Maar vanuit een leerperspectief is dat niet zo. Ruby heeft veel functies die eenvoudigweg niet eenvoudig zijn voor een beginnende programmeur om te begrijpen. Een dergelijk concept zijn blokken, procs en lambdas, die Rails veel gebruikt.

Het klassieke Ruby on Rails-voorbeeld dat ik zal gebruiken, is om een ​​formulier te maken:

  1. rAILS

Ruby is een dynamisch, imperatief objectgeoriënteerd programmeren. Het wordt dynamisch getypt, zoals in PHP, dus u hoeft zich geen zorgen te maken dat u variabelen moet opgeven. Rails is open source, werkt op meerdere platforms en kan worden ingesloten in Hypertext Markup Language. Het is een taal op zeer hoog niveau. Het biedt zelfs inkapseling van gegevensmethoden binnen objecten.

Ruby heeft super geavanceerde tekenreeks- en tekstmanipulatietechnieken kunnen eenvoudig worden verbonden met DB2, MySQL, Oracle en Sybase. Grote programma's geschreven in Ruby zijn gemakkelijk te onderhouden. Het heeft een schone en gemakkelijke syntaxis waarmee nieuwe ontwikkelaars Ruby zeer snel en gemakkelijk kunnen leren. Het heeft niet alleen de mogelijkheid om multi-threaded applicaties te schrijven met een eenvoudige API, maar biedt ook geavanceerde array-klasse en de mogelijkheid om externe bibliotheken in Ruby of C te schrijven.

Ruby Staat toe dat "gereserveerd woord" als een identificatie wordt gebruikt, zolang de parser geen dubbelzinnigheid waarneemt. In vergelijking met PHP heeft Ruby veel beveiligingsfuncties en krachtige stringverwerking.

Dus de vraag van het decennium is … Met al deze functies, maakt het Ruby een beter perspectief in vergelijking met PHP?

Helaas is het niet zo zwart en wit, en veel variabelen spelen een rol bij het bepalen of PHP of robijn op rails moet worden gebruikt om mee te ontwikkelen.

Ruby on Rails is bijvoorbeeld een veel complexere taal om een ​​ontwikkelomgeving in te richten. Bijgevolg verhoogt de stilzwijgende kennis die nodig is voor Ruby onmiddellijk de prijs in de programmeermarkt in vergelijking met PHP-ontwikkeling. Een PHP-ontwikkelaar daarentegen kan eenvoudigweg een conventioneel pakket zoals WAMP en MAMP gebruiken om hun dev-omgeving in minder dan 5 minuten op te zetten.

Toen ik in Ruby begon te coderen, brachten Gems me meer in de war dan ze hielpen omdat er teveel magie was. Toen ik eenmaal hoorde dat je gewoon de broncode voor edelstenen kon (en zou moeten) lezen, was alles zoveel logischer. Vanwege het inplugbare karakter van edelstenen en de normen van de community, kunnen edelstenen uw toepassing zeer snel een enorme hoeveelheid functionaliteit geven.

Enkele juweeltjes waar ik niet zonder kan: Devise (authenticatie - behandelt gebruikersaanmeldingen, sociale aanmelding, vergeet wachtwoordwerkstromen en nog veel meer), Paperclip (bestandsuploads - kan zelfs uploaden naar S3, beeld bijsnijden / opnieuw bemonsteren), eenvoudig Formulier maakt formulieren ongelooflijk eenvoudig te standaardiseren en weer te geven op websites.

PHP is ontworpen als een hypertext pre-processor, wat betekent dat het alleen wordt uitgevoerd wanneer er een webverzoek is. Vergeleken met Ruby, die een proces uitvoert. In Rails kunt u eenvoudig achtergrondtaken instellen met Sidekiq of Resque. Dit draagt ​​ook bij aan het vermogen van Rail om gemakkelijk te schalen. In onze applicaties verplaatsen we veel dingen die verzoeken kunnen vertragen, zoals het e-mailen van gebruikers naar achtergrondtaken.

Nu kan PHP achtergrondtaken uitvoeren met Gearman, maar dat is niet gestandaardiseerd - u moet de PECL-extensie installeren. In Ruby / Rails zijn achtergrondtaken geen probleem. Je doet het gewoon.

The Tug of War

Nu je veel over PHP en Rails hebt gelezen, kun je ze eens vergelijken. Laten we eens kijken welke gelijk staat wat betreft het gebruik van middelen en zelfs wat betreft de prestaties (snelheid).

Aanbevolen cursussen

  • Online certificeringcursus in Java-slaapstand
  • Programma op Java Spring
  • WordPress Certificatiecursus
  • Ruby Natuurlijk

Gebruik en snelheid van bronnen

In termen van geheugengebruik wordt het over het algemeen Python> Ruby> PHP, wat natuurlijk leidt tot Django> Rails> PHP. Niet alleen geheugen, maar dat heeft ook de neiging om voor rauwe robijn op rails versus php-prestaties te gelden. Ook vermeldenswaardig is hier dat er natuurlijk geen absolute waarden zijn. Er zijn tal van gebruiksscenario's waarin Ruby zonder twijfel Python zal verslaan. Ik denk dat we het er allemaal over eens kunnen zijn dat Ruby en Python altijd PHP zullen verslaan.

Mijn eigen ervaring is dat het geheugengebruik van Rails hoog kan zijn, vooral op 64-bits machines (minimaal is ongeveer 95-100 MB met zo dun als web front-end). PHP wordt meestal met verschillende patronen gebruikt, dus het is een beetje moeilijk om direct te vergelijken.

Dat gezegd hebbende, is het nog steeds erg eenvoudig om een ​​waardeloze, langzame en inefficiënte Django-applicatie en een lean, snelle en efficiënte Rails-applicatie te maken, of vice versa. Vaardigheid, kennis en expertise met het systeem dat u gebruikt, zullen veel meer doen voor zijn geheugen en prestatievoetafdruk dan alleen het framework zelf.

Database-optimalisaties, serverkeuzes en architecturen (Apache versus proxy-instellingen met behulp van nginx / lighttpd, enz.), En fundamentele ontwerpbeslissingen zullen de inherente kenmerken van het framework waarschijnlijk vrij snel overweldigen.

Als u typische benchmarks tussen Ruby en andere talen uitvoert, verliest Ruby. Ruby zou u waarschijnlijk niet goed van pas komen bij het schrijven van een realtime digitale signaalverwerkingstoepassing of een ander realtime controlesysteem. Ruby (met de huidige VM's) zou waarschijnlijk stikken op een computer met beperkte middelen zoals smartphones.

Vergeet niet dat veel van de verwerking op uw webapplicaties in feite gebeurt door software ontwikkeld in C. bijv. Apache, Thin, Nginx, SQLite, MySQL, PostgreSQL, veel parsing-bibliotheken, RMagick, TCP / IP, etc. zijn C-programma's die worden gebruikt door Robijn. Ruby zorgt voor de lijm en de bedrijfslogica.

De vraag is "WAAROM PHP dan?"

Laten we het nu hebben over PHP. PHP werkt extreem traag op apache-server. Zelfs als u een PHP-pagina probeert uit te voeren, zelfs zonder script, alleen een lege php-pagina, duurt het nog steeds 10 keer meer tijd om te laden in vergelijking met JSP's of Java. Maar nogmaals, de vraag van een miljoen eeuw is dat als dat zo is, waarom Facebook dan nog geen PHP heeft gedumpt? De reden waarom Facebook niet van PHP is geëmigreerd, is omdat de technici van Facebook erin zijn geslaagd om veel van zijn fouten te omzeilen door een combinatie van patches op alle niveaus van de stapel en uitstekende interne discipline via codeconventie en -stijl.

De slechtste kenmerken van de taal worden vermeden en de codestijl wordt strikt afgedwongen door een vrij strakke cultuur van codebeoordeling (het niet naleven van de stijl en "cowboy gaan" door slordige code te schrijven resulteert in meedogenloze spot door iemands collega's). Technisch management heeft hier nooit een sterke hand moeten pakken; dit is grotendeels te wijten aan belangrijke interne technische leiders die de rest van de tijd net zo goed deden.

En Facebook gebruikt natuurlijk niet alleen PHP. Het bevat ook C ++ als kern. Gebruik dus voor PHP een soort opcode-cache zoals APC of eAccelerator, anders moet PHP uw bestanden bij elk verzoek parseren. Voor algemene apache-tuning moet je wat googlen, een paar dingen zoals het uitschakelen van .htaccess-bestanden komen in me op, maar het moet nog steeds sneller zijn dan JSP.

Conclusie

Dus uiteindelijk denk ik dat ik zeg dat als je je een weg baant door Rails, je dan door Rails moet blijven zolang je niet van plan bent om een ​​geheel nieuw project op basis van PHP te starten en er een bedrijf mee te starten.

Aanbevolen artikelen

Hier zijn enkele artikelen die u zullen helpen om meer details over de Rails vs PHP te krijgen, dus ga gewoon via de link.

  1. Geweldige gids over de ontwikkeling van leerrails
  2. Ruby vs Ruby On Rails- Welke is beter?
  3. Ruby versus PHP-Welke technologie is het beste?
  4. Top 10 meest geweldige PHP-interviewvragen voor ervaren

Categorie:

Software ontwikkeling