Warum...

PHP + JavaScript

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

Warum…
… tut sich jemand noch PHP + Javascript an, wo es doch eine Kombi aus Rails + HAML + SASS + CoffeeScript gibt? Unkenntnis? Discuss!

Mine: Unkenntnis!


Rails ist auch ein Pain. Web ist ein Pain. End users are a pain. Discuss.


Weil PHP weit verbreitet ist und HAML, SASS und Coffeescript nicht sehr häufig benutzt werden.


Da ist was dran :wink:


Ach du, da gibt’s doch jede Woche eine neue tolle Programmiersprache samt komplettem Framework und allem, was dazugehört. Soll ich jetzt jedem Trend nachrennen und alles, was ich bisher gemacht hab, wegwerfen/neumachen/übersetzen? Soviel Zeit hab ich nun auch wieder nicht, das alles zu lernen. Ich verwende seit über 10 Jahren PHP. Und im Browser muss man ja HTML+CSS und JavaScript verwenden. Im Laufe der Zeit hab ich mir auch dafür einige Tools und eine Funktionsbibliothek erstellt. Dabei lernt man wenigstens noch was. Ich habe den Eindruck, dass vieles, was man so fertig abgepackt bekommt, nicht mehr sonderlich effizient ist. Oft kommt man bloß nicht mehr drum herum, es zu nehmen (siehe u.a. Windows, MS Office oder Eclipse). Webanwendungen mit PHP und JavaScript sowie Datenbankzugriffe über ADO.NET (ohne DataSets) sind eben so die ewigen Laster. Aber da ich mittlerweile blind weiß, wo ich hinlangen muss, und auf viel Code zurückgreifen kann, geht es bestimmt schneller als mit anderen Tools.

Manchmal finde ich PHP auch ziemlich unübersichtlich, und ich muss oft in der Online-Doku nachlesen, in welche Reihenfolge die Parameter nun gehören, weil das ziemlich inkonsistent ist. Ein schlauerer Texteditor könnte da wohl oft helfen. Aber letztlich ist PHP wahrscheinlich die am weitesten verbreitete Web-Programmiersprache, man kann sie auf jedem Webspace verwenden, die Performance ist mittlerweile ausreichend optimiert und es gibt viele Leute, die das verstehen und den Code verändern können.


Ich kann nur Netbeans empfehlen. Beste IDE, die ich bisher verwendet habe. Benutze es für Java und Web (PHP, HTML, CSS, Javascript, Smarty).


Die Frage ist die selbe wie die, warum jemand Java verwendet, wenn es C#+Mono gibt. Einige wissen es nicht besser, weil sie sich niemals ernsthaft mit einer Alternative befasst haben. Manche wollen sich die Arbeit des Umstiegs nicht machen und wieder anderen gefällt vielleicht wirklich irgendwas besonders gut an ihrer alten, gewohnten Umgebung.

Letztendlich läuft es aber wohl einfach darauf hinaus, dass die Leute das gleiche wie “die großen Firmen” verwenden. Und das ist nunmal Java bzw in deinem Fall PHP. Ich kenne Ruby on Rails nicht, vermisse jetzt aber (vielleicht abgesehen von Typsicherheit) auch kein konkretes Feature an PHP. Webanwendungen sind immer ein Gefrickel, spätestens wenn es um Sicherheit geht. Die Programmiersprache bestimmt da lediglich, auf welcher Website man nach Workarounds suchen kann.


Bei exotischen Sachen ist der Support halt meistens schlecht, und dann hilfts auch nicht wenn das Zeug in der Theorie total super ist.

Ich hab mal eine Rails-Seite gemacht, die ich dann beim Rails-Upgrade nicht mehr fixen konnte.
Auch wenn PHP natürlich der totale Schrott ist, hätten da wohl sicher Millionen andere User das gleiche Problem gehabt und irgendeiner hätte es gelöst.

Ähnliche Erfahrungen hab ich grad mit Scala gemacht. Dauernd Probleme mit der IDE oder den Build-Tools. Mit Java wäre ich schon lange fertig.

C#/Mono ist auch sone Sache. Zwar um einiges ausgereifter als Scala, aber dann doch nervig im Vergleich zu Visual Studio wegen häufigen Crashes von Monodevelop.
(Und wenn man für mobile Geräte entwickeln will kostets jetzt richtig Kohle wenn ich das richtig sehe. NON-FREE!!)


Genauso dachte ich eben bis vor kurzem auch, bis ich mich mal näher damit beschäftigt habe. Verwendest du ein PHP-Framework?

Was ich bei Rails vorteilhaft finde: Die extreme Kürze und Lesbarkeit des Codes, und die ganzen Gems aus der Entwicklergemeinde, welche noch mehr „Magic“ bringen.

also Schutz gegen XSS, CSRF und Injections sind praktisch built-in.

Uff das hört sich schon total nach Werbung an, jedenfalls bin ich nur ziemlich begeistert. :wink:

Nun ja man findet eigentlich immer recht schnell Hilfe in Stack Overflow oder Railsforum.

Lol, genau den gleichen Satz habe ich vor 1,5 Monaten zu meinem Kumpel der mich auf Rails gebracht hat gesagt. Das rührt daher, dass man viel Magic noch garnicht kennt, der syntaktische Zucker ist Irrsinn.

Mal so ein paar kleine Beispiele:

class User < ActiveRecord::Base
  validates :tos, :acceptance => true, :on => :create
  
  validates :nickname,  :length     => { :in => 3..25},
                        :presence   => true,
                        :format     => { :with => /\A[ äöüÄÖÜßa-zA-Z0-9\$\_\-\~\*\!\.]*\z/ },
                        :uniqueness => { :case_sensitive => false }
  
  validates :email,  :length       => { :in => 3..200},
                     :presence     => true,
                     :uniqueness   => { :case_sensitive => false },
                     :confirmation => true
                     
  validates :password, :presence     => true,
                       :confirmation => true,
                       :length       => { :within => 6..50 }, :on => :create

  #associations
  has_many :posts, :dependent => :destroy
	
  has_one :user_level, :dependent => :destroy

  #filter	
  before_create :encrypt_password
end

daraus resultierend gibts dann gratis:

user = User.find(42) #finde user 42
user.posts.all #gib mir alle posts eines users
user.user_level.builder_level
user.post.create(...) #erstelle einen zum user zugehörigen post

IMO liest sich das wie von selbst. Schlägt ein Validator fehl gibts die Fehlerbeschreibungen in einer schönen Fehlerbox automatisch:

<%= form_for(@user) do |f| %>
<%= render 'shared/error_messages', :object => f.object %>

...

<% if object.errors.any? %>
  <div id="error_explanation">
    <ul>
    <% object.errors.full_messages.each do |msg| %>
      <li><%= msg %></li>
    <% end %>
    </ul>
  </div>
<% end %>

Aber ok, erstmal genug FanBoy-Geblubber. Vielleicht noch: Eigentlich sollte das für die Linuxer hier unter uns, dass richtige sein, da vieles kommandozeilenbasiert läuft und git quasi-standard ist :wink:

Was ich sagen will, wenn jemand vorhat frisch ins Web einzusteigen, kann man mal einen Blick drauf werfen :wink:

Railscasts sind auch immer nett anzusehen für neue Inspirationen


Nimm halt irgend ein PHP-Framework, dann haettest du das fast genauso schreiben koennen. Sogar mit gescheiter E-Mail validierung und nicht nur “zwischen 3 und 200 zeichen”. Ich find’s ziemlich Schwachsinnig ein Framework mit einer Programmiersprache zu vergleichen… Ruby gegen PHP, Rails gegen $tollesPHPFramework von mir aus… aber so…


Ich seh schon, ich steh noch relativ am Anfang was Webzeug angeht :slight_smile:


Das ist halt genau der Punkt, der Rails ambivalent macht. Den Erfahrungsbericht, bzw. die Begeisterung kann ich aus eigener Erfahrung auch bestätigen.
Andererseits, wenn der Code erst mal eine Weile liegt, man ein paar magische Seiteneffekte genutzt hat in einer Railsversion, die mittlerweile veraltet ist, dann kann es sein, dass man genau deswegen Schwierigkeiten mit seinem Code bekommt. Es kann passieren, dass die Kausalitäten in dem Framework durch die Magie verdeckt werden.


Ich kann mir kaum vorstellen, dass Rails keine Email-Validierung per Regex out-of-the-box kann? Gibt doch bestimmte etwas a la [m]:email => true[/m]?

Davon abgesehen, warum die Mindestlänge von drei Zeichen? Die TLD ist doch schon mindestens zwei Zeichen lang, plus den Punkt, plus mindestens ein Zeichen für den 2nd-Level-Domain-Name (wobei, gibt es überhaupt eine TLD, die kürzere 2nd-Level-Domains als zwei Zeichen erlaubt?), plus das @, plus mindestens ein Zeichen davor ergibt mindestens 7 Zeichen für eine gängige Email-Adresse. Aber das nur nebenbei.

Klar, Magic ist natürlich nett beim entwickeln, aber die Probleme gehen dann los, wenn man an einen Punkt kommt, an dem man etwas anders lösen muss, als der Framework das vorsieht. Aber das ist halt einfach ein Nachteil von “convention over configuration”. Ich habe zum Thema CI-Systeme mal einen netten Spruch gelesen, der so halbwegs auch auf Web-Frameworks passt (und vermutlich auch ziemlich viele andere Software auch). Den genauen Wortlaut weiß ich nicht mehr, aber der Sinn war etwa: Richtig gut funktionieren sie nur für zwei Projekte: Ihr eigenes und das, für das sie ursprünglich entwickelt wurden.


lol regexp email validation.


lol.


FYI http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html


Na, auch wenn sich das so ein Hardcore-Informatiker wie du nicht vorstellen kann, aber so lol ist das nun auch wieder nicht. Natürlich gehts nicht darum, eine absolut wasserdichte Überprüfung vorzunehmen, wenn letztendlich sowieso eine Email zwecks Double-Opt-In rausgeht. Aber es macht als kleine Hilfe für den Benutzer durchaus Sinn ein relativ lockeres regex drüber zu schicken, um einfache Tippfehler (Komma statt Punkt, etc.) und ähnliches zu erkennen und dem Benutzer zumindest darauf hinzuweisen, dass das so nicht ganz stimmen kann. Es ging nicht darum jede falsche Adresse zu erkennen. Ist sowieso sinnfrei, da auch eine formal richtige Adresse eine “falsche” im Sinne des Seitenbetreibers sein kann, also nicht existiert oder jemandem anders gehört,…



Wie wahr, leider sehe ich nicht nur Nutzer von Computern so…