Ersetzt HTML5 / JS schließlich alle clientseitigen Sprachen? [geschlossen]

12

Ich wundere mich nur über die Zukunft von allem. IMHO gibt es 4 Kräfte, die definieren, wohin die Technologie geht: Microsoft, Apple, Google, Adobe.

Es sieht so aus, als ob in Apples iPhone / iPad iADs jetzt in HTML5 programmiert werden können. Bedeutet das, dass HTML5 schließlich Objective-C ersetzen wird?

Außerdem hat Microsoft seinen Fokus jetzt von WPF / Silverlight auf HTML5 verlagert, und ich gehe davon aus, dass sich Visual Studio 2011 ausschließlich mit der Unterstützung von Tools für HTML5 befassen wird. Denn genau das macht Microsoft. (Werkzeuge). In einigen Monaten wird der IE9 den HTML5-Standard des letzten großen Browsers unterstützen.

Ebenso steigt Adobe in den HTML5-Bereich ein und ermöglicht das Exportieren von Flash-Inhalten in HTML5 mit den neuesten Tools.

Und wir alle wissen, wie viel Google mit HTML5 zu tun hat. Heck, ihr neuestes Betriebssystem (Chrome OS) ist nichts anderes als ein fetter Webbrowser.

Apps für Handys (z. B. iPhone, Android, WM7) sind für ein Unternehmen sehr schwer zu programmieren, insbesondere für viele verschiedene Geräte (jedes in einer eigenen Sprache). Ich gehe daher davon aus, dass dies nicht allzu lange dauern wird. Das heißt, HTML5 wird die verbindende Sprache sein. Was für App-Entwickler etwas traurig ist, denn jetzt können Benutzer die "coolen" html5-Apps kostenlos im Web spielen und es wird schwierig sein, sie in Rechnung zu stellen.

Sind also stark typisierte Sprachen wirklich zum Scheitern verurteilt, und wird die clientseitige Programmierung in Zukunft, beispielsweise in 5-10 Jahren, nur noch in HTML5 erfolgen? Werden wir alle Javascript-Programmierer? :) Weil die Schilder sicher in diese Richtung weisen ...


quelle
1
Diese Befürworter der fortschrittlichen Verbesserung müssen inzwischen in ihren Gräbern liegen.
Gio Borje
2
Wollen Sie damit sagen, dass die Vorteile des starken Tippens nicht mehr benötigt werden?
Aaron Anodide
1
Ich denke, es wird VS 2012 sein, nicht VS 2011.
DeadMG
6
Wenn das der Fall ist, muss ich mich nur umbringen.
Job
2
Ich habe es satt, mir Sorgen um die Browserkompatibilität zu machen. Es ist so verdammt kindisch.
The Muffin Man

Antworten:

14

Ich denke, es ist falsch, vorzuschlagen, dass HTML5 / JS ALLE clientseitigen Sprachen ersetzen wird . Gehen in den kommenden Jahren viele Anwendungen so? Ja möglicherweise. Werden sie alle? Nein.

Der andere wichtige Punkt ist, dass sich die Landschaft ständig verändert. HTML5 ist eine großartige Technologie, die viele der Probleme lösen wird, die Entwickler derzeit haben, wenn sie versuchen, Anwendungen zu schreiben, die plattformübergreifend funktionieren. Sicher, HTML5 / JS kann viele dieser Probleme lösen, aber die Landschaft wird sich ändern und es werden neue Probleme auftauchen. HTML5 scheint irgendwann veraltet zu sein.

Fragen Sie sich in 10 Jahren, ob HTML5 / JS die Lösung für alle Probleme war, und ich kann fast garantieren, dass die Antwort Nein sein wird. In 20 Jahren wird die Frage selbst wahrscheinlich lächerlich erscheinen.

Damovisa
quelle
+1 Ich stimme vollkommen zu. Schauen Sie ein wenig in die Geschichte zurück, das "Neueste und Größte" wird immer durch das neue "Neueste und Größte" ersetzt. Das ist ein Teil dessen, was an der Programmierung so großartig ist, dass es sich immer weiterentwickelt.
Beth Whitezel
Die Dinge entwickeln sich jedoch mit unterschiedlicher Geschwindigkeit - wie die Interaktion der Computerbenutzer - Lochkarten, dann Tastaturen, dann Mäuse. Ich frage mich oft, was als nächstes kommt, da sich dies als grundlegender Umbruch bei der Entwicklung von Client-Anwendungen und 3D erweisen könnte Tastatur maus? Ich denke schon - wenn auch nicht sicher, wann.
Aaron Anodide
6

Javascript ist eine sehr schlechte Programmiersprache. Die Übersetzung aus statisch typisierten Programmiersprachen wie Java mit GWT wird immer häufiger. Javascript wird möglicherweise zu einer einheitlichen Sprache wie Assembler - Sie können direkt darin schreiben, aber es ist selten eine gute Idee.

Don Reba
quelle
1
Ich kenne mich nicht nur mit statisch getippten Sprachen aus, aber wenn Sie jQuery oder MooTools oder ähnliches
hineinwerfen
8
Ich bin mit Ihnen nicht einverstanden, dass JavaScript eine schlechte Sprache ist, dies ist absolut nicht korrekt! :) Wie es scheint, gibt es viele faule Programmierer, die seit vielen Jahren Java oder eine andere serverseitige Sprache beherrschen und sich nicht durch das Erlernen neuer Sprachen verbessern wollen. Sie sagen, JavaScript ist schlecht: D Aus diesem Grund gibt es so viele Tools und Frameworks zum Generieren von JavaScript mit serverseitigen Sprachen! JavaScript ist kein Web-Spielzeug, es ist eine echte Sprache!
Zango
Ich stimme auch nicht zu. Ich glaube, es ist ein unangebrachter Kommentar, so etwas über JavaScript zu sagen. Viele Fachleute und erfolgreiche Produkte würden nicht zustimmen. Die Zeit ist der beste Test, und bisher leistet JS hervorragende Arbeit, um die technische Uhr zu überstehen.
Ich kann mir nicht vorstellen, warum ich es vorziehen würde, 50 Zeilen Java zu schreiben, in der Hoffnung, dass meine Änderung im laufenden Betrieb ausgetauscht werden kann, wenn ich zehn Zeilen Javascript schreiben und die Seite einfach neu laden könnte. Oder wurden Neustarts des Webservers beseitigt, als ich nicht hinschaute?
Kevin Cline
5
Ich habe während meiner Karriere kommerzielle Software in ungefähr einem Dutzend Sprachen geschrieben und ich schreibe täglich JavaScript. JavaScript ist eine vernünftige Sprache, wenn man bedenkt, dass sie 1995 über einige Wochen entwickelt und implementiert wurde. Trotzdem kann ich JavaScript-Entschuldiger nicht verstehen. Es weist schwerwiegende Mängel auf, bei denen verantwortliche Programmierer bestimmte Sprachmerkmale vollständig vermeiden und andere in einer Weise verwenden müssen, die ursprünglich nicht beabsichtigt war, um fehlende Funktionen bereitzustellen. Vielleicht nutzen sie es nicht für große Projekte? Ich habe festgestellt, dass die Verwendung für große Systeme mit vielen Codierern relativ schwierig ist.
PeterAllenWebb
1

Ja.

Hier ist der Grund. Apps bestehen aus Benutzeroberflächencode und Back-End-Daten. Der Benutzeroberflächencode wird in HTML5 / CSS3 / Javascript ausgeführt. Back-End-Code kann proprietär sein und in jeder Sprache ausgeführt werden. Darüber hinaus können jQTouch und ähnliche Bibliotheken verwendet werden, um iPhone-ähnliche Benutzeroberflächen zu emulieren, jedoch als Open Source-Version und in Javascript / HTML5 / CSS geschrieben. jQTouch hat gezeigt, dass, wenn der Browser JS-Programmierern Zugriff auf die Benutzeroberflächenereignisse des Geräts gewährt, JS-Programmierer den für dieselbe Plattform aktuellen Benutzeroberflächenstil emulieren.

Javascript-Programmierer werden gefragter denn je sein. In einer Model-View-Controller-Architektur befinden sich das Modell und der Controller im Back-End, der View-Code wird jedoch am besten im Browser geschrieben. zB HTML5, Javascript, CSS. Und Sie müssen JS-Code schreiben, um auf die Back-End-Daten zuzugreifen, insbesondere mit starkem AJAX-Code.

Die Produktivitätssteigerungen werden alle auf die dynamisch interpretierten Sprachen entfallen. Da Prozessoren immer schneller werden, wirken sich die Programmierproduktivität, die Sysadmin-Produktivität und die Produktivität von App-Administratoren stärker auf die Gesamtproduktivität aus. Sie müssen sich einfach keine Gedanken mehr darüber machen, wie schnell die VM oder der Compiler Ihrer Programmiersprache ist. Sie müssen sich jetzt mehr Gedanken darüber machen, wie viel es kostet, Ihre App bereitzustellen und zu unterstützen.

Die meisten eigenständigen Apps sind meiner Meinung nach nicht so toll. Genauso wie es nur wenige großartige eigenständige PC-Apps gibt, und die besten werden in Web-Apps umgewandelt. Es ist besser, die HTML / JS / CSS-Client-App kostenlos zu verschenken und eine monatliche Gebühr für den Zugriff auf die Back-End-Daten und die Geschäftslogik zu berechnen. Programmierer werden Abonnements besser verkaufen als One-Shot-Apps.

In diesem Video erfahren Sie übrigens , wie Sie einen Teil einer eigenständigen Web-App in einem Webkit-Browser schreiben . Es ist interessant...

Jay Godse
quelle
1
Nun, eine nette Sache bei "One-Shot" -Apps ist, dass Sie zumindest nicht den ganzen nervigen Benutzernamen / das ganze Passwort wie Sie überall im Web eingeben müssen. Zustand wird lokal gespeichert. Viele clientseitige Apps benötigen auch kein Back-End. Denken Sie an Flash-Spiele. Und wer in aller Welt kauft ein Abonnement für Fußball-Flash-Spiele für Mütter? Niemand. Und wer in aller Welt kauft mobile Apps? jeder. Leider fürchte ich, dass HTML5 die Apps töten wird. Es war schön, wenn unabhängige Entwickler einmal Geld verdienten.
@Schnitzel - Unabhängige Entwickler verdienen Geld, wenn sie auch ein Backend aufbauen.
Jay Godse
2
-1 für "Die Produktivitätsgewinne werden alle auf die dynamisch interpretierten Sprachen gehen" - das ist meiner Meinung nach sehr falsch. Ich bin viel produktiver in statisch getippten und kompilierten Sprachen wie Scala. Ich finde Fehler direkt in meiner IDE viel schneller als bei dynamischen Sprachen wie PHP, Python und Ruby.
Jonas
Ich kann wirklich keinen Nutzen für die Verwendung von PHP / Ruby / Python anstelle von Scala sehen.
Jonas
@Jonas - Ihre eigene Frage unter programmers.stackexchange.com/questions/7516/… legt nahe, dass dynamische Sprachen das Produktivitätspaket anführen.
Jay Godse
1

Es besteht der Wille, Programmiersprachen wie C ++, Java ... durch HTML / Javascript zu ersetzen. Dafür gibt es viele Gründe, einige davon:

  • Schnellere Entwicklung
  • Billigere Arbeitskräfte
  • Konnektivität ist eingebaut
  • Leichter etwas zu produzieren, das gut aussieht
  • Der Text ist für Index-Engines zugänglich

Möglicherweise werden jedoch andere Sprachen als Ersatz für JavaScript verwendet. Schließlich ist es schwierig, eine Sprache zu haben, die alles richtig macht und dabei ein hohes Sprachniveau beibehält! Und JavaScript gibt es schon seit einiger Zeit und hat einige Mängel angehäuft.

JavaScript könnte sehr wohl die Hauptsprache für Kunden sein, aber ich denke nicht, dass es die einzige Sprache sein kann oder sollte , da JS eine standardgetriebene, vom Komitee entworfene Sprache ist, die Innovation einfach töten wird auf dieser Ebene (Programmiersprachen).

Rolf
quelle
0

Dies hängt auch von den Fähigkeiten der meisten Entwickler und den von ihnen verwendeten Tools ab. Die von Ihnen genannten Technologieriesen können eine Technologie basierend auf den von ihnen bereitgestellten Tools entwickeln. Zum Beispiel sagen die Leute, HTML5 sei ein Flash-Killer, aber ich denke, das ist zu weit entfernt, da es viele Flash-Entwickler gibt, und es ist eine gewaltige Aufgabe, ihre Fähigkeiten auf JavaScript umzustellen. Was schließlich passiert, bleibt die Fähigkeit gleich, aber die Ausgabe wird unterschiedlich. In diesem Fall wird Adobe mit dem HTML5-Konvertierungstool ausgeliefert.

Außerdem müssen Sie über die Leistung von Clientanwendungen nachdenken. Wo es erforderlich ist, wird ein plattformspezifisches Tool verwendet. Nimmt zum Beispiel Spiele und iOS-Apps auf. Ich weiß, dass WebGL gut herauskommt, aber ich habe das Gefühl, dass die Leute immer noch C verwenden, um Spiele zu erstellen. Oder sie erstellen eine Spielsprache, die Hochleistungsspiele erstellt. Apple wollte anfangs nur Webapps, aber als Entwickler die Wunder von Cocoa sahen, sprangen sie darauf, um elegante Apps zu erstellen.

Zusammenfassend wird es immer neue Tools / Sprachen / Technologien geben, die immer cooler sind als die aktuellen.

Manish
quelle
0

Nicht alle, aber wahrscheinlich die meisten. Vielleicht kann Javascript schnell genug werden, um HashCalc zu ersetzen, aber es gibt keine Alternative zu VLC im Internet (Browser unterstützen nicht alle diese Codecs). Ich bezweifle, dass Webbrowser mir den Zugriff auf eine beliebige Datei gestatten oder eine Liste der zuletzt verwendeten Dateien speichern (ohne dass jedes Mal, wenn ich auf die zuletzt verwendete Datei klicke, ein "ist dies in Ordnung" angezeigt wird). Die Idee, Apps zu verteilen, die zu 99% aus Webbrowsern bestehen, gefällt mir nicht (mehrere mb) mit meinen 100kb Code, wenn es um Fälle geht, in denen Code kaputt geht. bc Browser sind nicht abwärtskompatibel mit dem HTML oder ich benötige eine Variante / leichte Modifikation des Webkits.

-edit- auch ich mag eher statische als dynamische Sprachen, aber ich gehe davon aus, dass ich mit LLVM eine gute Sprache verwenden kann, die vom Browser unterstützt werden sollte.


quelle
-1

Ich denke, wir werden so lange in diese Richtung gehen, bis der Browser zum Betriebssystem wird und dann alles in der gleichen Reihenfolge neu gestartet wird, aber mit den gewonnenen Erkenntnissen und Verbesserungen.

Aaron Anodide
quelle