Schepp, Kahlil und Hans quatschen über APIs, die sich von Frameworks-Features zu Browser-APIs entwickeln.
Schaunotizen
- [00:01:39] Meta-Frameworks
- Kahlil hat auf der React Rally einen berichtenswerten Talk von Nicole Sullivan alias @stubbornella aufgeschnappt. Thema ist die Zusammenarbeit des Chrome-Teams mit diversen Framework-Entwicklern, bei der das Ziel ist, den Browser zu einer besseren Plattform für die diversen Web-Frameworks zu machen. Eine wichtiges Takeaway aus dem Talk ist die offizielle Google-Empfehlung, Meta-Frameworks wie Next.js (ein Wrapper um React) und Nuxt.js (ein Wrapper um Vue) einzusetzen um Performance-Best-Practices wie SSR auf Framework-Ebene zu etablieren. Aus der Zusammenarbeit zwischen React und Google sind unter anderem die Main thread Scheduling APIs und isInputPending in Chrome zurückgeflossen. Wir quatschen über 7 Principles of Rich Web Applications, create-react-app, Frameworks allgemein, Server-Side Rendering, HTML5 Boilerplate, Ember Fastboot, Code Splitting, CSS Modules (nicht das JS-Projekt), Web Components, GatsbyJS, Uberspace und mögliche Gründe gegen den Einsatz von Meta-Frameworks.
Kommentare
Tobias Barth #
Geschrieben am 10.12.2019 um 19:47
Der wichtigste Kommentar zuerst: Next ist das beste seit geschnitten Brot und fast jeder kann und sollte es verwenden. Insbesondere im Enterprise-Kontext, weil man schneller an ein sehr gutes Produkt kommt, als wenn man die Optimierungen alle selber macht.
Zum Thema Hosting: Geht auch. Next hat eh schon sogenannte „automatic static optimization“, was bedeutet, wenn deine Seiten keine dynamischen Daten brauchen, du also keine „getInitialProps“ Methoden definiert hast, fällt einfach statisches HTML, CSS und JS aus „next build“ raus, das man gegen Strato oder 1&1 und Konsorten werfen kann. Wenn man dynamische Daten mit „getInitialProps“ holt, macht „next export“ (statt „build“) was ähnliches wie Gatsby: Es führt die Methode beim build aus und rendert dann alles statisch raus, was es kann. Ergebnis ist auch hier: Kein NodeJS-Hosting benötigt. Die einzige Einschränkung dabei ist natürlich, dass beim Build nichts erzeugt werden kann, das auf Request-Daten beruht. Wie … na ja … wie bei statischen Seiten eben. https://nextjs.org/docs#static-html-export
Und noch zu der Frage, warum sich Menschen dagegen sträuben, das einzusetzen. Ich glaube es ist eine unheilige Mischung aus Not-Invented-Here-Syndrom (eher bei EntwicklerInnen) und Hab-ich-noch-nie-gehört-das-kann-ja-nichts-für-seriöse-Firmen-sein (eher bei Business-Menschen). Ersteres ist das viel Schlimmere glaube ich. Da wird dann geglaubt, das bei zeit.co sind so Emporkömmlinge, die sich ja nur auf dem Rücken von React ausruhen und da abgreifen; da wird geglaubt, so lange dauert das gar nicht, das alles selber einzurichten (Erzählerstimme: „Docht, dauert es.“); da wird geglaubt man ist aber doch eine Schneeflocke, die ganz besondere Ansprüche und Wünsche hat und man sich deshalb nicht einem opinionated Meta-Framework „unterwerfen“ kann (Unfug: dein Code wird nur besser dadurch) und so weiter und so weiter. Grauenhaft. Da hilft nur immer wieder darüber sprechen, sich auch gern mal Externe holen, die darüber sprechen, vielleicht sogar mal nen Hackathon veranstalten (Wer ist schneller besser, Eigenbau oder Next?) oder ähnliche Sachen. Dicke Bretter bohren.
Latz #
Geschrieben am 12.12.2019 um 01:34
all-inkl konnte mir auf Anfrage nicht mitteilen, wann und ob überhaupt node.js in den Shared-Hosting Paketen (also diejenigen, die sich ein Freizeit-Programmierer leisten möchte) angeboten wird.
Leider scheint es schwierig, einen Shared-Hosting-Anbieter mit ähnlichen sonstigen Features zu diesen Preisen zu finden, der node.js anbietet.
Schepp #
Geschrieben am 12.12.2019 um 07:08
Genau so ist es. Mir wäre wirklich kein einziger Massenhoster bekannt, der das kann. Am nächsten dran kommen Digital Ocean und Heroku.
Lars Moelleken #
Geschrieben am 12.12.2019 um 21:15
Zum Thema Frontend-Frameworks, was ist den momentan und zukünftig für große legacy Serverside-Application zu verwenden? (ggf. Schritt für Schritt Umbau, oder Hybrid,…?)
Habe hier ein ziemlich großes PHP Projekt, mit guter modularer Struktur, dass bereits einen gescheiterten Angular relaunch hinter sich hat. Das Problem war hier, dass man >10 Jahre Entwicklung nicht einfach so einfach neu bauen kann. Die Idee ist nun, dass man ggf. ein Frontend-Framework findet, welches sich in bestehen Code integrieren lässt ohne direkt alles neu schreiben zu müssen. ?
Hatte mir z.B. tinybind / riba.js angeschaut, kleine libs die man einfacher in ein bestehendes System integrieren kann? Aber ggf. ist ein größeres Framework mit besserem Support + mehr Features besser? Hat da jemand bereits Erfahrungen?
Mfg Lars
Peter #
Geschrieben am 13.12.2019 um 15:12
Was ist denn das Ziel des Rewrites? Es gibt sicher ein passendes Werkzeug für den Job, aber ich bin mir nicht ganz sicher was der Job ist.
Lars Moelleken #
Geschrieben am 16.12.2019 um 14:48
Zunächst würden wir gerne einen Rewrite verhindern, für 95 % der Views ist das alles auch gar kein Problem, da hier ein paar in PHP gewrapped Ajax Funktionen ausreichen.
Wenn Jedoch etwas Kompliziertes gebaut wird, würde ich mit etwas Hilfe von einem Framework bzw. Libary wünschen Stichwort Offline-First, Two-Way-Databinding, View-Models.
Mfg Lars
Peter #
Geschrieben am 17.12.2019 um 11:25
Das hört sich für mich nach einem Job für Vue an. Wenn ihr Webentwickler im Team habt, die ihr normales jQuery/Ajax-JS selektiv in eine etwas moderne Form überführen wollen, ohne alles auf einen Schlag neu zu machen, würde ich mir genau das mal anschauen. Bei sowas wie tinybind oder riba.js würde mir der Bus-Faktor ein wenig Sorge bereiten.
Lars Moelleken #
Geschrieben am 18.12.2019 um 20:45
Danke für die Rückmeldung. ?
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.