News Microsoft erklärt den .NET-Stack zu Open Source

[nintendoluk]

Ich mag Microsoft c-:

(Windows mag ich aber trotzdem nicht :-P)

 

[SheepShaver]

Java wird damit mehr und mehr obsolete.

Da geschätzte 90% aller Enterprise Software auf Java basiert und sich daran in den nächsten Jahren nichts ändern wird, wohl kaum.

Als .NET Entwickler finde ich es klasse, aber Java wird jetzt hart zukaempfen haben. .NET hat mit den angeboten Tooling und den intenen/externen Libaries in der Enterpriseentwicklung einen extremen Vorsprung zu Java.

Das ist völliger Blödsinn, es ist eher andersherum. Es gibt bis dato immer noch keinen wirklich brauchbaren auf .NET basierenden ESB.

Also ich hab mit beidem Entwickelt: Java ist einfach nur grauenhaft und eine absolute Zumutung.

Begründung?

Ich habe auch mehrere Jahre in ziemlich großen J2EE-Projekten gearbeitet, und der Eindruck, der mir bis heute aus dieser Zeit bleibt ist: nicht funktionierende Tools, Boilerplate-Code und irgendwie war alles ätzend (ich denke da ans Deployment).

Die Meinung könnte man teilen, wenn man seine Erfahrungen auf die zweite Hälfte des letzten Jahrzehnts beschränkt. Mittlerweile gibt es eine Unzahl an lightweigt Integration-Frameworks und auch EJB ist seit 3.0 brauchbar und hat das Gros an Boilerplatecode abgeschafft.

 

[carom]

Java ist die durchdachteste Sprache der Welt.

Java mag alles sein, aber sicherlich nicht die durchdachteste Sprache der Welt. Da kann die Sprache selbst gar nichts dafür, das liegt einfach daran, dass sie historisch gewachsen ist und die meisten Neuerungen einfach aufgesetzt wirken. Das wurde mit Java 8 nochmal deutlich schlimmer.

Ironietags vergessen? Schon mal was von Python gehört? Leichter, schneller durchdachter als Java

Leichter und von mir aus auch durchdachter. Aber schneller definitiv nicht. Python ist und bleibt eine interpretierte Skriptsprache mit all ihren Vor- und Nachteilen. Bei Python wird vielleicht der Bytecode gecached, aber der kommt bei Java bereits aus dem Compiler raus. Für kleinere Dinge ist Python sicher performanter, weil die Startup-Zeit nicht so groß ist wie bei der JVM, aber bei allem anderen fährt Java Kreise um Python.

Aber ja, man kann anstelle von C++ ja auch gerne Java verwenden. Das mag zwar die Entwicklungszeit halbieren, und dann kommt man drauf dass das ganze Langsam wie Sau ist und fängt an zu "optimieren", was leider aussichtslos ist weil die Java-VM von gewissen Operationen komplett überfordert ist.

Wenn der Einsatzzweck auf Hardwarenähe und unabdingbare Performance abzielt, dann ist etwas anderes als nativ eben die falsche Wahl. In allen anderen Fällen dafür nicht.
Du unterschätzt die JVM etwas. Das ist das wertvollste, was Java hervorgebracht hat, selbst wenn man Java links liegen lässt und andere Sprachen auf der JVM nutzt (wie Scala oder Clojure). Wenn dir die JVM zu langsam ist, dann kannst du nahezu alles außer nativen Sprachen wie C/++ auch gleich in die Tonne kloppen, denn es gibt nicht viel, was sonst noch vor der JVM liegt. Vielleicht ein paar Exoten wie Google Go oder D, das war's dann auch schon. Und der Tradeoff von Performance kommt ja nicht von ungefähr, sondern man erhält einen Gegenwert, allem voran der überwachte Speicherbereich.

 

[heidegger]

[...] und Blackberry eine JVM, nur halt nicht die von Oracle.

Blackberry 10 hat keine JVM und unterstützt Java auch nicht mehr offiziell. Die Android-Apps laufen mittels einer Android-Runtime (ist technisch gesehen eigentlich ein kompletter Fork von Android) innerhalb einer Sandbox. Native Anwendungen für BB10 müssen in Qt/C++ sein.

 

[nintendoluk]

Was mich bei Java nervt ist diese Signieren-Pflicht* seit Java 7_52 -.-

Ansonsten ist Java Top! Nur die IDEs sind nicht gar so gut (vor allem Eclipse )

EDIT:
* Bei Applets

 

[Fonce]

Das ist kein kompletter Android Form sondern von dessen JVM. Das gleiche macht z.B. Jolla. Dortblaufen auch Android Apps drauf mittels einer eigenen Implementierung der Dalvik JVM.

 

[noxon]

Nein, sie ist nicht etwas vollkommen anderes. Sie bietet nicht alle Funktionen der Oracle JVM, aber das ist kein Kriterium dafür das es eine JVM ist.

Also wenn du stackbasierte und registerbasierte Programmausführungen nicht als etwas völlig unterschiedliches betrachtest, dann weiß ich nicht was du als Unterschiedlich definieren würdest.
Das ist auf grundlegensterweise unterschiedlich, unterschiedlicher geht es gar nicht.

 

[Mischu_]

Ist schon interessant wie da die MS und .NET Welt die Ideologie wechselt wie andere die Schlüpfer. Es ist noch keine 10 Jahre her, als die Aussage von mir bekannten .NET Entwicklern bezüglich Open Source generell war, dass es dort nur so von 3. Party Libs wuchert und deshalb die Stabilität darunter leidet. Wer die Ironie findet, darf diese behalten.

Btw ... erst einmal muss MS Visual Studio auf andere Plattformen portieren. Ich persönlich arbeite ausschliesslich auf und mit Linux ... und da setze ich mir sicher keine Win VM auf, wenn die Runtime unter Linux relevant ist.
Noch was zum Thema IDE. Meiner Erfahrung nach haben viele Entwickler die mit Java ein Problem hatten eigentlich mit Eclipse ihre Mühe und nicht mit Java an sich... Ich selber arbeite seit Jahren auch nur noch mit Intellij IDEA, da ich Eclipse auch nicht viel abgewinnen kann.

Was der Vergleich Java vs. .NET anbelangt ... Ich persönlich entwickle seit nun mehr über 10 Jahren auf Java im Enterprise Umfeld. Habe aber gute Kumpels welche gleich lang oder länger in der .NET Welt unterwegs sind und wir uns austauschen. Von daher erlaube ich mir ein Urteil.
Bei .NET fällt die Auswahl an Lösungen wohl einfacher, da es im gesamten einfach weniger Auswahl gibt ... von daher entfällt auch die Diskussion über die Möglichkeiten . Ein gutes Beispiel sind Ansätze in der Java Welt wie das Google Web Toolkit, welches z.B. nahe stateless serverseite sessions ermöglicht, da fast 100% stateful clients. Einen solchen Ansatz gibt es in der .NET Welt meines Wissens nicht.
Wenn es z.B. um fachliche RIA's geht, welche Workflows etc. beinhaltet (unterm Strich schlicht eine gewisse Menge session Daten generiert ... wenn auch nur temporär) ... summiert mit einer nicht so kleinen Anzahl gleichzeitig aktiver Benutzer ... Kann dies gut und gern in den GB Bereich an reinen Benutzer-Sitzungsdaten gehen. Aber bei MS ist man sichs ja gewohnt mit RAM ned gerade sparsam umgzugehen.

Ich würde mal behaupten, dass viele die hier nen Java shit-storm lostretten, noch nie WIRKLICH mit Java in einem professionellen Umfeld gearbeitet haben. JEE 6 und 7 sind einfach nur cool.
Dazu muss ich sagen, dass mir das Ökosystem um Welten wichtiger ist als die fancyness einer Sprache wie C#. Middleware im Allgemeinen ist so ein gutes Thema.

Mac OSX, Linux schön und gut ... aber was ist z.B. mit AIX, Solaris? Nur mal so

Ich bin mal auf folgendes gespannt:
- Wie lange es dauert, bis das ganze stabil ist.
- Wie sich das .NET Ökosystem entwickelt, denn man brauchte ja das was .NET bietet und sicher keine 3. Party Lib.
--- Dies in anbetracht dessen, dass MS sich selber nun hausgemachten Inkompatibiltäten ausliefert wie Active Directory - LDAP usw.

Ich persönlich sehe das Vorgehen eher als Versuch eine Welt mit schräglage zu retten. Wenn eine Firma dieser Grössenordnung innerhalb von relativ kurzer Zeit einen solchen Ideologiewechsel durchführt, hat dies nicht unbedingt eine aus Firmensicht positive Ursache.

 

[Kassenwart]

Ein gutes Beispiel sind Ansätze in der Java Welt wie das Google Web Toolkit, welches z.B. nahe stateless serverseite sessions ermöglicht, da fast 100% stateful clients. Einen solchen Ansatz gibt es in der .NET Welt meines Wissens nicht.

Bietet ASP .NET MVC nicht genau das gleiche wie das GWT ?

 

[StockholmSyndr.]

How Microsoft lost the API war

 

[captmcneil]

Ist schon interessant wie da die MS und .NET Welt die Ideologie wechselt wie andere die Schlüpfer. Es ist noch keine 10 Jahre her, als die Aussage von mir bekannten .NET Entwicklern bezüglich Open Source generell war, dass es dort nur so von 3. Party Libs wuchert und deshalb die Stabilität darunter leidet. Wer die Ironie findet, darf diese behalten.

Das ist jetzt aber wirklich mehr "Genörgel" als fundierte Kritik... Ich erinnere mich an die ASP.Net AJAX Control Library, eine von Microsoft gepushte Open Source Bibliothek mit neuen Controls. Und die Code-Qualität da war wirklich unterirdisch.

Open Source alleine sagt überhaupt nichts über die Qualität aus. Nur weil der Code frei ist, wirds nicht automatisch besser. Im Falle einer Firma wie Microsoft macht OS halt keinen Sinn, wenn das ganze nicht durchgezogen wird, und MS selbst das ganze nicht auch irgendwie managt. Nen Haufen übermotivierte Entwickler ranlassen mit den Worten "macht mal" führt auch zu nichts.

Man kann durchaus diskutieren, ob die Haltung "damals" einfach zu konservativ oder gänzlich falsch war, aber mehr auch nicht.

Was der Vergleich Java vs. .NET anbelangt ... Ich persönlich entwickle seit nun mehr über 10 Jahren auf Java im Enterprise Umfeld. Habe aber gute Kumpels welche gleich lang oder länger in der .NET Welt unterwegs sind und wir uns austauschen. Von daher erlaube ich mir ein Urteil.
Bei .NET fällt die Auswahl an Lösungen wohl einfacher, da es im gesamten einfach weniger Auswahl gibt ... von daher entfällt auch die Diskussion über die Möglichkeiten . Ein gutes Beispiel sind Ansätze in der Java Welt wie das Google Web Toolkit, welches z.B. nahe stateless serverseite sessions ermöglicht, da fast 100% stateful clients. Einen solchen Ansatz gibt es in der .NET Welt meines Wissens nicht.
Wenn es z.B. um fachliche RIA's geht, welche Workflows etc. beinhaltet (unterm Strich schlicht eine gewisse Menge session Daten generiert ... wenn auch nur temporär) ... summiert mit einer nicht so kleinen Anzahl gleichzeitig aktiver Benutzer ... Kann dies gut und gern in den GB Bereich an reinen Benutzer-Sitzungsdaten gehen. Aber bei MS ist man sichs ja gewohnt mit RAM ned gerade sparsam umgzugehen.

Da ist was wahres dran. Wer seriös entwickelt, sollte auch nicht weiter gehen, als "ich fühle mich bei Java einfach nicht wohl". Dass Java nichts taugt, ist direkt widerlegt durch die riesige Anzahl an riesengroßen Projekten, die damit gut laufen. Und auch wenn ich zuvor geschrieben habe, was ich alles aus meiner Java-Zeit nicht vermisse, so habe ich auch den Eindruck mitgenommen, dass gerade diese Riesenprojekte überdurchschnittlich oft eine ordentliche Architektur und guten Code vorweisen können.

Auf der Anderen Seite könnte man nun sagen, dass es in Java auch gar nicht anders möglich ist, größere Projekte zum laufen zu bekommen, da man ohne 10 Jahre Berufserfahrung in dem Feld gar nicht in der Lage wäre, die richtigen Bibliotheken, Tools usw. zusammenzusuchen. Das, was eingangs über die "3rd-Party-Bibliothekenhölle" erwähnt wurde, ist (und war damals) in Java halt Realität, wenn man nicht extrem sorgfältig auswählt, was man sich an Bord holt. Zum Thema GWT: ist was für Leute, die kein JavaScript programmieren wollen, und keineswegs ein Universalwerkzeug. Ich würde es nicht benutzen.

Da ist man auf dem MS-Stack halt einfacher dran - für Web ist's ASP.Net, für Dependency Injection Unity, für Webservices WCF, und so weiter. Klar kann man sich jetzt drüber streiten, ob mehr Vielfalt nicht besser wäre, aber am Ende zählt für den Entwickler doch nur, "wo fühle ich mich wohler?".


Ich hab dazu das Gefühl, dass es in der Java-Community extrem viele Leute gibt, die schon viel zu lange nichts anderes mehr gesehen haben. Die müssen halt aufpassen, nicht so zu enden wie heute zB COBOL - als Haufen von hochintelligenten Fachidioten, die sich nie was anderes angeschaut haben, "weil es ja schon immer wunderbar funktioniert hat". Endlos komplexe Workflows, mit noch endlos komplexeren Datenmodellen, die irgendwann keiner mehr umstellen oder modernisieren kann. Man darf hier auch gerne an die unbelehrbaren C-Entwickler denken, die seit 100 Jahren nichts anders machen, und alles andere schlechtreden, weil sie meinen es zu kennen, es aber nicht wirklich tun.

In sofern sollte jeder Java-Entwickler froh um diese Entwicklung von Microsoft und .Net sein. Es gibt Java einen Grund, sich weiterzuentwickeln. Konkurrenz und so :-)

 

[Mischu_]

Open Source sagt in der Tat nichts über die Code Qualität aus, jedoch bedingt was über das Ziel und die Motivation des Herstellers. Das grösste Argument von .NET war bis anhin ja, dass .NET alles aus einem Guss liefert. Dieses Argument wird mit diesem Schritt obsolet (nur so n Beispiel die Inetgration von JQuery). Wieso? Ganz einfach, Microsoft verlässt ihr eigenes Ökosystem. Ich rede hier nicht von kleinen Tools, sondern es geht um Enterprise Applikationen (Systemen) welche mit Umsystemen interagieren müssen. Hier ist die Auswahl sehr gross, ich nehme hier nochmals LDAP und z.B. NFS oder Samba als Beispiele.

Viele .NET Entwickler jubeln jetzt, o geil, wir erobern nun die Linux Welt ... mit ner API, nem Plattform Ökosystem das klar auf MS Umgebungen ausgelegt ist? Doch eher fraglich! Die Rolle von MS wird sich nun klar ändern. Bis anhin war MS der Lieferant von allen Lösungen, es steht nirgends geschrieben (meines Wissens), wer nun die Schnittstellen zu anderen Ökosystemen spezifiziert und standardardisiert.
Ich kann mir z.B. vorstellen, dass Microsoft's Rolle nun so ändert (aus meiner Sicht müssen sie dies), dass sie entweder Community driven (wie bei Java) oder selber Use Cases ihrer .Net Plattform standardisieren. Und das ist der grosse Teil der Aufgabe.
.NET in open source zu überführen ist aus meiner Sicht in der ersten Phase nur ein Marketing Gag.

Genau dies macht Oracle, respektive die Java Welt seit längerem sau gut. Man hat eine Sammlung von JSR's, welche jeweils einen Use Case abdecken (Beispiel Websockets, oder JNDI). Ein Superset dieser ergibt dann jeweils den sogenannten Java Enterprise Edition Standard (kurz JEE im Moment aktuell 7). Anhand dieser gibt es dann Middleware welche für den jeweiligen Standard zertifiziert sind und als Grundwerk dienen können (schaue JBoss Applicationserver). Für komplexere Applikationen oder Systeme gibt es in der Java Welt heute wohl 3 Stacks. Den Spring Stack, den Oracle Stack mit der WebLogic Fusion Middleware als Basis und meine Wahl den JBoss Stack mit dem JBoss AS als Basis. Hierbei hat fast genauso kein library Massaker, ausser natürlich man hat das Gefühl man könne es besser als die Standards und deren Referenzimplementierungen.

Das coole bei JBoss ist, dass man WIRKLICH contributen kann, auch zu Referenzimplementierungen zu Standards welche von ihnen kommen wie z.B. JSR-299 (CDI / WELD). Um zu zeigen, dass dies keine leeren Wort sind, hier ein Link zu meinem contributing zu Errai (CDI integration für GWT)

Ich bin nun gespannt, wie MS das handhabt wenn die ersten Linux, oder MacOSX Projekte mit .NET starten und .NET eben, dann mal keine Haus-Lösung für ein Problem bietet. Genau hier ist Potenzial für einen Library Wucher, wenn kein Standard definiert ist.

MS hat aus meiner Sicht 2 Möglichkeiten, entweder sie produzieren alles Notwendige selber (jetzt aber für alle Ökosysteme) oder sie gehen dazu über Standard's zu spezifizieren um die Integration zu gewährleisten. Mit "hui jetzt sind wir open source, hat ein .NET Entwickler noch lange nicht Rüstzeug für eine non-MS Ökosystem Lösung zu entwickeln".

Von daher an die .NET Welt ... willkommen und schaut, dass ihr nicht dieselben Probleme habt wie andere vor 10 Jahren

Noch schnell zum Thema GWT. Ähnliche Ansätze gibt es auch in der .NET, aber diese gehen nicht soweit (meines Wissen, ASP .NET MVC weiss ich nicht im Detail, mal anschauen) ... Die Aussage, dass seih für Leute die nicht gerne Javascript entwickeln ... dies ist nicht ganz falsch aber auch nicht ganz richtig. Bei gewissen Sachen musste und kannste genauso selber bei und mit Javascript Hand anlegen. Und alles selber zu implementieren, ist sicher möglich jedoch gibt es hierzu verdammt viele Punkte wie Value binding, Validierung, Parsing etc. welche eben schon gelöst sind.
Die riesen Vorteile sind:

- Man entwickelt den Server UND den Client in Java (nicht Javascript) ... mit Einschränkungen bezüglich Reflection API. Was der Code Quali extrem gut tut.
- Der Clientteil der Applikation ist REIN Javascript (kein HTML Traffic)
- Wie bereits geschrieben nahezu 100% stateful Clients
- GWT kommt von Google und wird nachwievor gepflegt

Bezüglich dem Tunnelblick von Java Entwicklern, ich glaube dass ganze auf jeden Entwickler abmünzen der sich mit seiner Wahl identifiziert, dies schliesst auch .NETler mit ein (man kucke das Java bashing in diesem Thread). Ich selber habe zeitweise auch C++ (ebenfalls Visual C++) entwickelt, wie auch Perl, persönlich habe ich jedoch meine Domain gefunden. Schaue aber auch gerne andere Sachen an wie vor kurzem Google Dart an, welches wirklich auch n cooler Ansatz ist. Das .NET respektive vorallem C# gegenüber Java als Sprache Vorteile bietet ... kein Thema. Aber das Ökosystem kannste bei .NET ned vergleichen, da MS spezifisch. Und ganz ehrlich, die Mentalität von MS find ich vorallem seit dieser Meldung ... hmmm ... nicht identifizierbar.

Aber definitiv ... Konkurrenz belebt das Geschäft

 

[Kassenwart]

Hier ist die Auswahl sehr gross, ich nehme hier nochmals LDAP

Was geht den mit LDAP nicht ? Ich habe diverse LDAP Projekte in .NET umgesetzt. Probleme gab es keine. Weder mit AD, Novell eDirectory oder anderen Verzeichnisdiensten.

Die riesen Vorteile sind:

- Man entwickelt den Server UND den Client in Java (nicht Javascript) ... mit Einschränkungen bezüglich Reflection API. Was der Code Quali extrem gut tut.
- Der Clientteil der Applikation ist REIN Javascript (kein HTML Traffic)
- Wie bereits geschrieben nahezu 100% stateful Clients
- GWT kommt von Google und wird nachwievor gepflegt

Ich sehe immer noch nicht was an GWT da jetzt so toll sein soll. Das gleiche kann ich mit MVC auch. Unsere Clients sind auch Stateful.

 

[Euphoria]

Es ist schon witzig. Erst wird immer über den Status Quo gemeckert und wenn sich dann mal etwas ändert, dann ist man dennoch nicht zufrieden.

Na das war doch damals bei der XBOX One genauso...
Es ist schlecht, wenn man auf Feedback nicht reagiert, wenn man es aber tut hat man kein Rückgrat und ist auch mies.

Egal wie man es macht, es wird immer Leute geben, denen die was zu meckern haben.

Ich finde die Entwicklung von Microsoft gut und das machen viele. Auch die Börse nimmt das ganze positiv auf, wie man in den letzten Wochen gesehen hat.

 

[captmcneil]

Open Source sagt in der Tat nichts über die Code Qualität aus, jedoch bedingt was über das Ziel und die Motivation des Herstellers. Das grösste Argument von .NET war bis anhin ja, dass .NET alles aus einem Guss liefert. Dieses Argument wird mit diesem Schritt obsolet (nur so n Beispiel die Inetgration von JQuery). Wieso? Ganz einfach, Microsoft verlässt ihr eigenes Ökosystem. Ich rede hier nicht von kleinen Tools, sondern es geht um Enterprise Applikationen (Systemen) welche mit Umsystemen interagieren müssen. Hier ist die Auswahl sehr gross, ich nehme hier nochmals LDAP und z.B. NFS oder Samba als Beispiele.

"Integriert" ist jQuery imho nicht. Mal ganz ehrlich, wer hat denn jemals freiwillig die Microsoft AJAX-Library benutzt? Ich sehe nicht, wie man heute in ASP jQuery anders einsetzt als vor 10 Jahren.

Dass Microsoft hier sein Ökosystem verlässt, sehe ich überhaupt nicht. Für das, was MVC zB heute alles standardmäßig einbindet, hatte Microsoft bisher nichts, oder es war einfach nicht optimal, und die Leute haben eh längst was anderes benutzt (zB das Client Validation Framework für ASP). Niemand hat jemals irgendwem vorgeschrieben, was für Client-Bibliotheken man für seine Webanwendung verwenden soll.

Das einzige, was ich sehe, ist, dass Microsoft sein Ökosystem festigt und verbessert. Es ist ja nicht so, dass ASP.Net nur aus 3rd Party-Bibliotheken besteht (das sehe ich wie gesagt nur bei dem CSS/JS-Zeugs). Der Kern (Razor, Controller, Routing) ist von Microsoft.

Viele .NET Entwickler jubeln jetzt, o geil, wir erobern nun die Linux Welt ... mit ner API, nem Plattform Ökosystem das klar auf MS Umgebungen ausgelegt ist? Doch eher fraglich! Die Rolle von MS wird sich nun klar ändern. Bis anhin war MS der Lieferant von allen Lösungen, es steht nirgends geschrieben (meines Wissens), wer nun die Schnittstellen zu anderen Ökosystemen spezifiziert und standardardisiert.

Ich zitiere hier mal aus Platzgründen nicht alles.
Ich denke, Du interpretierst hier mehr rein, als da ist. Deine Bedenken haben Hand und Fuß, aber ich sehe nicht, wie es besser wäre, den Schritt nicht zu gehen.

Ich glaube eben *nicht*, dass sich die meisten Firmen, die derzeit auf .Net entwickeln, einen Ast abfreuen, dass die Programme jetzt auf Linux laufen können. Allein schon dass viele Programme auf den SQL Server optimiert sind, wird Grund sein, da nicht umsteigen zu wollen.

Ich glaube eher, das ganze dient auch dazu, Windows Phone relevanter zu machen. Microsoft muss den App-Entwicklern einfach Flexibilität geben, wenn sie wollen, dass die Killerapps halt auch für Windows rauskommen. Wenn man dazu noch sieht, dass die größte Schwäche in der native Android-Entwicklung eben die Tools sind, ist das doch ein super Hebel, um die Entwickler auf die eigenen Tools wechseln zu lassen.

Ich kenne mehrere Situationen in meinem beruflichen Umfeld, wo größere .Net-Anwendungen jetzt auf einmal eine Mobile-Variante brauchen - und WP reicht hier einfach nicht. Es ist doch nur logisch, dass Microsoft hier reagiert.

Noch schnell zum Thema GWT. Ähnliche Ansätze gibt es auch in der .NET, aber diese gehen nicht soweit (meines Wissen, ASP .NET MVC weiss ich nicht im Detail, mal anschauen) ... Die Aussage, dass seih für Leute die nicht gerne Javascript entwickeln ... dies ist nicht ganz falsch aber auch nicht ganz richtig. Bei gewissen Sachen musste und kannste genauso selber bei und mit Javascript Hand anlegen. Und alles selber zu implementieren, ist sicher möglich jedoch gibt es hierzu verdammt viele Punkte wie Value binding, Validierung, Parsing etc. welche eben schon gelöst sind.

Es gab in WebForms den ViewState, und es hat sich als... nicht so gut rausgestellt :-)

MVC hat den Ansatz, dem Web-Entwickler Kontrolle über das Output-HTML/JS zu geben, während ASP WebForms die Philosophie hatte, das ganze ein bisschen wie WinForms (ziehe Controls aus der Toolbox auf die Seite, und wir machen den Rest) aussehen zu lassen. Problem ist halt, das ist Schrott, wenn die Controls an ihre Grenzen stoßen - man ist halt einfach in diesem sehr komplexen Lifecycle mit ViewState, PostBacks, Callbacks, Events etc. gefangen. Das wollen Web-Entwickler einfach nicht.

Das was ich bei GWT sehe, ist einfach nur "mehr WebForms": Noch mehr Framework drumrum, um dem Entwickler das Gefühl zu nehmen, er ist im Web. Das mag für Business-Anwendungen, die nur aus Formularen und Masken bestehen, passen; aber man hat hier definitiv einen riesigen Kompromiss.

Spätestens, wenn Du mit den F12-Tools im Browser Fehler suchst, musst Du einfach wissen, wie Deine Seite gerendert wird.

Zuletzt: DataBinding ist jetzt nicht wirklich eine Besonderheit von GWT. Das kann nun wirklich jeder... Die Frage ist eher, wie gut und flexibel ist es umgesetzt? Auch hier ist MVC ziemlich stark.

 

[L0g4n]

.NET ist zwar ne gute Sprache für Windows, jedoch denke ich nicht, dass Anwendungen so "butterweich" (wie hier einmal gesagt wurde) auf anderen Betriebssystem laufen werden wie auf Windows. Gründe wurden hier schon genannt, .NET benutzt aktuell viel mehr interne Systemaufrufe und Java abstrahiert komplett.
Und immer dieses sinnlose Java Gebashe find ich auch zum Kotzen, vor allem weil viele nur mit ihrem Halbwissen um sich herschmeißen.

 

[captmcneil]

Gründe wurden hier schon genannt, .NET benutzt aktuell viel mehr interne Systemaufrufe und Java abstrahiert komplett.

Das ist einfach falsch. Wie soll Java "komplett" abstrahieren? Wie willst Du einen Button durch Abstrahierung anzeigen? Selbst rendern? Wie abstrahierst Du dann das Zeichnen? Kannst Du Abstrahierung überhaupt definieren? Ich glaube nämlich, Du benutzt das nur als Buzzword. Soviel zu "Halbwissen".

Java hat einfach viele offizielle Implementierungen der Runtime, .Net nur eine. Und auch bei den Java-Implementierungen wird das Schlüsselwort "native" ziemlich oft benutzt.

Schau Dir mal XAMARIN an, wenn Du dort einen Button definierst, wird ganz schön abstrahiert. Unter Windows ist es ein Windows-API-Button, unter Mobile halt nicht. Funktioniert wunderbar.

 

[L0g4n]

Das meine ich ja auch genau, .NET muss nur seine bekannte WinApi aufrufen, dagegen die Java Runtime muss je nach OS spezifische "Befehle aufrufen". Ich hatte einfach es einfach formuliert, da ich nicht groß hier einen Roman, der jetzt genau beschreibt wie Java das auf verschiedenen OS lauffähig macht, schreiben wollte, sondern nur meine Meinung. Ich meine eher, dass .NET sehr viele Windows spezifische Optimierungen für ihre GUIS usw. drinnen hat, unter anderen Betriebssystem wird man da schon eine Unterschied merken.

LG

 

[noxon]

vor allem weil viele nur mit ihrem Halbwissen um sich herschmeißen.

Vorsicht bei dem was du hier sagst. Besonders nach dem was du da gerade gepostest hast.