Für alle die noch Ihre Rechnungen noch mit Word oder ähnlichem schreiben, Ihr könnt euch hier registrieren.

https://www.salesking.eu/

Wir werden wöchentlich neue User zulassen, bitte habt etwas Geduld.

Ansonsten könnt Ihr unseren Twitter Stream oder Blog verfolgen.

Ja … und wir sind der Meinung, es ist sogar essentiell auf diese Weise zu starten.

Dass diese Meinung in der Web2.0 Startups keine große Verbereitung hat, findet man schnell heraus indem man diverse Webservices einmal ohne Javascript besucht.

Doch warum gehen wir diesen, zugegebenermaßen steinigen Weg? Es ist doch so einfach die in Ruby on Rails oder anderen Frameworks verfügbaren Javascript-Helferlein zu verwenden? Nicht zuletzt sind solche Javascript Code-Generatoren ja auch für den Erfolg vieler Frameworks verantwortlich.

Die kurze Antwort:

Wir wollen die Kontrolle über unser Javascript behalten!

Die lange Antwort :

Unauffälliges / Unobstrusive Javascript

Es soll dem User nicht auffallen wenn er die Seite ohne Javascript benutzt. “Wer hat denn schon JS ausgeschaltet?”, ist meist die Gegenfrage. Jede größere Firma, welche halbwegs auf ihre interne Netzsicherheit achtet, wird/sollte JS ausgeschaltet haben. Ein weiterer Vorteil dieser Restriktion ist übrigens, daß die Mitarbeiter sich auf Ihre Arbeit konzentrieren, da das Internetz keinen Spass mehr macht.
Auf mögliche JS basierte Angriffe will ich hier nicht weiter eingehen, Google hilft aber gerne weiter:

http://www.google.de/search?q=Javascript+angriff

Spagetti Code und enge Kopplung vermeiden

Ist die Soße, in diesem Falle JS, erst einmal auf den Nudeln, ist es so gut wie unmöglich sie wieder von den Spagetti zu trennen. Die enge Kopplung von zwei intelligenten Sprachen, bzw. das Generieren von JS mittels PHP, Ruby, Java; macht die folgenden Punkte so gut wie unmöglich:

• JS Fehler finden / Debuggen
• JS Sicherheitslücken finden
• JS Schnelligkeit und Effizienz Testen / Profiling
• Austausch der Soße(JS) je nach Client (IE / mobile Webbrowser / iPhone / ..)
• Wiederverwendung von JS z.B. in einer komplementären Adobe Air Anwendung oder Widgets

Wem diese Punkte nicht reichen, ein weiteres Beispiel:

Bevor CSS in seiner heutigen Anwendung(komplette Trennung von CSS / HTML) populär wurde, schrieben wir es einfach mit in die jeweiligen HTML-Elemente. Kam dann der Kunde und wollte neue Farben, war es ein Heidenspass 150 HTML Dateien anzupassen.

Wie Kontrolle behalten?

Der einzig richtige Weg ist: Lerne Javascript und du wirst es lieben!

Auch ich habe mit den tollen JS Helfer in Rails und cakePHP angefangen, ohne einen blassen Schimmer von der Materie zu haben. Das Ende vom Lied war ein dreckiger Haufen Code und x vertane Stunden mit drei Fragezeichen über meinem Kopf. Das waren übrigens, vor zwei Jahren, die ersten Versuche den SalesKing zu bauen.
Nachdem 3 Versuche und drei Monate Arbeit im Müll gelandet waren, habe ich mich tiefer mit jQuery und Javascript beschäftigt. Es ging nicht von heute auf morgen, doch ein halbes Jahr später hatte ich meine Javascript-Angst überwunden, unter anderem durch das Ormigo Dschungelcamp und Teemow.

Das populärste Javascript-Müll Beispiel ist übrigens seit langem in WordPress, zu finden, die „Artikel schreiben“ Seite enthält 14 Javascripte. Chaos deluxe und keiner weiß warum es noch funktioniert!!!

Unsere Vorgehensweise

Wir sehen in JS den Zucker auf dem Kuchen. Im Gegensatz zu Schokostücken, kommt dieser erst nach dem Backen zum Einsatz.

Der Programmier-Ablauf sieht grob wie folgt aus:

1. Programmieren der Basisfunktionen ohne JS, dafür mit vielen Zwischenseiten.
2. Testen
3. Einbinden der Basis JS Scripte
4. simple ergonomische Verbesserungen z.B. Show/Hide funktion für vormals sichtbare Elemente
5. erweitern des (php/ruby) Code um Schalter zur Erkennung ob es sich um JS-initierte Abfragen handelt (xhr-requests)
6. erweiterte JS Funktionen z.B. direkte Auslieferung von vorherigen Zwischenseiten (z.B. Löschen Dialog) in einer Thickbox. Oder konsumieren vom xml/json Rückgabewerten aus nr. 5.
7. JS Tests / Packing