SWC konzentriert sich darauf, wie Babel kompatiblen JavaScript-Code zu erzeugen und sogar das Bundling zu übernehmen; hier liegt der Fokus dagegen darauf, TypeScript-Code in JavaScript umzuwandeln oder Fehler zu prüfen.
Das entspricht ziemlich genau meiner eigenen Erfahrung.
wenn ich einfachen, aber schwer zu merkenden Code schreiben muss (Datei-Ein/Ausgabe, Arbeiten mit Containern usw.)
wenn Compiler- oder Laufzeitfehler auftreten und ich herausfinden muss, was für ein Fehler das ist und welcher Code ihn verursacht
wenn ich eine Funktion neu schreiben möchte, die einer bereits vorhandenen ähnelt, aber etwas andere Funktionalität haben soll
wenn ich Code, der von einer bestimmten Bibliothek abhängt, durch eine andere Bibliothek oder durch eigene Funktionen ersetzen möchte
wenn ich für die Implementierung einer bestimmten Funktion oder für die Arbeit in einer bestimmten Umgebung eine Anleitung brauche, wie ich die Entwicklung angehen soll
In solchen Fällen habe ich ziemlich viel Zeit gespart. Mit der Kombination aus Google + Stack Overflow findet man vieles oft nicht gut, und besonders bei Stack Overflow gab es häufig nervige Situationen, in denen es zwar eine Antwort gab, aber in den Kommentaren ständig Einwände erhoben wurden oder gesagt wurde, dass es eine Implementierung aus einer alten Version sei und man sie nicht verwenden solle ...
Wenn man in Zeiträume von 1–2 Wochen aufteilt, scheint es ganz natürlich, dass nur ein begrenzter Kreis von Personen das Gesamtbild einer einzelnen Funktion kennt. So wie beim Unterschied zwischen Prozess und Thread. Man begrenzt den Fokus und steigert dadurch die Produktivität.
Selbst wenn man dieses Bild teilt, setzt das voraus, dass Fragen dazu aufkommen würden; zugleich habe ich offenbar auch ganz selbstverständlich vorausgesetzt, dass man das große Ganze nicht im Blick behalten kann, wenn sich die Richtung bei jedem Sprint Planning Stück für Stück verändert.
Sollte es nicht darum gehen, das große Ganze zu teilen und die Arbeit in kleine Tasks aufzuteilen, nachdem sichergestellt ist, dass alle es verstanden haben??
Wenn man Aufgaben in so kleine Tasks aufteilt, bekommt die Führungskraft mit dem Gesamtbild sehr viel Macht. Die mitarbeitenden Engineers werden dadurch eher demotiviert und fragen sich: „Worauf arbeiten wir hier eigentlich hin?“ Ein typischer Nachteil von sprintbasiertem Agile.
Es wirkt, als wäre der Text zu sehr nur aus der Perspektive der Führungskraft geschrieben – genau wie der Titel sagt.
Das Momentum von Engineers wird auch stark davon beeinflusst, in welche Richtung die Führungskraft die Flagge hält. Es scheint mir, dass man auch etwas mehr darüber nachdenken sollte, wie man vermitteln kann, welchen Wert man den Kunden geben will und was der Output und das Delivery-Outcome jedes Sprints sein sollen. Natürlich sind das schwierige Soft Skills, daher sieht man nur selten Führungskräfte, die das wirklich gut können, und es gibt auch nicht viele gute Texte darüber.
Ich kann .NET nachvollziehen, aber ich denke, dass Rust eher auf derselben Ebene wie Go steht. Wahrscheinlich haben auch bereits bestehende Go-Projekte und -Bibliotheken rund um JS diese Entscheidung beeinflusst.
Das ist wirklich eine sehr originelle Idee, aber wie in anderen Kommentaren frage ich mich auch, wie sie das Problem lösen werden, wenn der Traffic stark ansteigt.
> Wenn TypeScript-Code nicht mehr in TypeScript geschrieben wird, könnte das Team TypeScript selbst nicht mehr direkt verwenden, was sich langfristig auf die Developer Experience auswirken kann.
Man sagt ja, man isst sein eigenes Hundefutter – also nutzt selbst, was man gebaut hat. Aber bei einer Programmiersprache gibt mir das doch etwas zu denken.
Wenn man allerdings die neuesten Technologien (?) einführen will, wird man nicht selten von JUnit4 ausgebremst, daher habe ich persönlich den kleinen Wunsch, dass auf JUnit5 migriert wird. https://docs.gradle.com/develocity/test-distribution/
Mit junit-vintage-engine lassen sich JUnit4-Tests zwar auch ohne große Änderungen unter JUnit5 ausführen, der Overhead ist jedoch ziemlich hoch. (ungefähr 20 % langsamer)
Es gibt zwar keine Angaben zur koreanischen Leistung, aber nach dem Ausprobieren sieht es nicht schlecht aus.
Wenn es Funktionen zur Umgehung von Anti-Bot-Maßnahmen hätte, könnte es wohl zum Gewinner des Marktes werden.
Die Debatte scheint ziemlich heiß zu sein – Anders Hejlsberg hat persönlich einen Kommentar hinterlassen.
https://github.com/microsoft/typescript-go/…
Ja, genau das!
Jemand, der sich wünscht, dass beim Kompilieren mit TypeScript das Ergebnis direkt als Binärdatei herauskommt
Vielen Dank für den Hinweis auf dieses gute Material.
SWC konzentriert sich darauf, wie Babel kompatiblen JavaScript-Code zu erzeugen und sogar das Bundling zu übernehmen; hier liegt der Fokus dagegen darauf, TypeScript-Code in JavaScript umzuwandeln oder Fehler zu prüfen.
Das entspricht ziemlich genau meiner eigenen Erfahrung.
In solchen Fällen habe ich ziemlich viel Zeit gespart. Mit der Kombination aus Google + Stack Overflow findet man vieles oft nicht gut, und besonders bei Stack Overflow gab es häufig nervige Situationen, in denen es zwar eine Antwort gab, aber in den Kommentaren ständig Einwände erhoben wurden oder gesagt wurde, dass es eine Implementierung aus einer alten Version sei und man sie nicht verwenden solle ...
Wenn man in Zeiträume von 1–2 Wochen aufteilt, scheint es ganz natürlich, dass nur ein begrenzter Kreis von Personen das Gesamtbild einer einzelnen Funktion kennt. So wie beim Unterschied zwischen Prozess und Thread. Man begrenzt den Fokus und steigert dadurch die Produktivität.
Selbst wenn man dieses Bild teilt, setzt das voraus, dass Fragen dazu aufkommen würden; zugleich habe ich offenbar auch ganz selbstverständlich vorausgesetzt, dass man das große Ganze nicht im Blick behalten kann, wenn sich die Richtung bei jedem Sprint Planning Stück für Stück verändert.
Sollte es nicht darum gehen, das große Ganze zu teilen und die Arbeit in kleine Tasks aufzuteilen, nachdem sichergestellt ist, dass alle es verstanden haben??
Vielen Dank für den guten Beitrag.
Wenn man Aufgaben in so kleine Tasks aufteilt, bekommt die Führungskraft mit dem Gesamtbild sehr viel Macht. Die mitarbeitenden Engineers werden dadurch eher demotiviert und fragen sich: „Worauf arbeiten wir hier eigentlich hin?“ Ein typischer Nachteil von sprintbasiertem Agile.
Es wirkt, als wäre der Text zu sehr nur aus der Perspektive der Führungskraft geschrieben – genau wie der Titel sagt.
Das Momentum von Engineers wird auch stark davon beeinflusst, in welche Richtung die Führungskraft die Flagge hält. Es scheint mir, dass man auch etwas mehr darüber nachdenken sollte, wie man vermitteln kann, welchen Wert man den Kunden geben will und was der Output und das Delivery-Outcome jedes Sprints sein sollen. Natürlich sind das schwierige Soft Skills, daher sieht man nur selten Führungskräfte, die das wirklich gut können, und es gibt auch nicht viele gute Texte darüber.
Mit Frontend kenne ich mich nicht aus … ist das etwas anderes als swc?
Es ist gerade 8:40 Uhr morgens, und als ich gedankenlos hingeschaut habe, stand da genau 7:40:28 PM EST ... wie faszinierend.
Ein Besuch bei McDonald’s scheint einfach zu sein. Es klingt nach einer unterhaltsamen Erfahrung.
Ich kann .NET nachvollziehen, aber ich denke, dass Rust eher auf derselben Ebene wie Go steht. Wahrscheinlich haben auch bereits bestehende Go-Projekte und -Bibliotheken rund um JS diese Entscheidung beeinflusst.
Das ist wirklich eine sehr originelle Idee, aber wie in anderen Kommentaren frage ich mich auch, wie sie das Problem lösen werden, wenn der Traffic stark ansteigt.
Sie meinen vermutlich eine Runtime wie Node; hier geht es jedoch um den Compiler der TS-Sprache selbst.
> Wenn TypeScript-Code nicht mehr in TypeScript geschrieben wird, könnte das Team TypeScript selbst nicht mehr direkt verwenden, was sich langfristig auf die Developer Experience auswirken kann.
Man sagt ja, man isst sein eigenes Hundefutter – also nutzt selbst, was man gebaut hat. Aber bei einer Programmiersprache gibt mir das doch etwas zu denken.
Wenn man allerdings die neuesten Technologien (?) einführen will, wird man nicht selten von JUnit4 ausgebremst, daher habe ich persönlich den kleinen Wunsch, dass auf JUnit5 migriert wird.
https://docs.gradle.com/develocity/test-distribution/
Mit
junit-vintage-enginelassen sich JUnit4-Tests zwar auch ohne große Änderungen unter JUnit5 ausführen, der Overhead ist jedoch ziemlich hoch. (ungefähr 20 % langsamer)