Razzle: Starten einer neuen App

Erstellt am 5. Juni 2017  ·  5Kommentare  ·  Quelle: jaredpalmer/razzle

Dieses Projekt sieht fantastisch aus. Ich werde ein neues Projekt erstellen und habe mich nur gefragt, ob next.js, create-react-app und razzle die Vorteile haben oder was langfristig am besten wäre. Ich würde SSR wirklich mögen, also kommt CRA wahrscheinlich nicht in Frage. Ich habe mit next eine App gebaut und bin dann auf dieses Projekt gestoßen. Hoffentlich ist dies ein guter Ort, um dies zu fragen, aber ich wollte nur ein paar Gedanken darüber bekommen, was langfristig am besten ist.

discussion

Hilfreichster Kommentar

Danke @knipferrc

Eine ähnliche Erfahrung hat mich dazu gebracht, Razzle zu entwickeln.

Vor ungefähr 6 Monaten habe ich direkt nach dem Erscheinen eine riesige App mit Next.js gestartet, und die Abwanderung war zu groß für mich. Ich habe den PR für das parametrisierte Routing-Beispiel (dh /user/:id ) buchstäblich eingereicht. Ich erinnere mich, dass ich wegen eines seltsamen Fehlers im Zusammenhang mit dem Abfeuern von getInitialProps bei Routenänderungen eine ganze Woche Arbeit verloren habe . Am Ende des Tages trifft Next.js viele sehr wichtige Entscheidungen für Sie (z. B. Routing, Datenabruf, Ordnerstruktur und Styling). Ob diese gut oder schlecht sind, hängt ganz von der Art der Anwendung ab, die Sie erstellen. Wie sich herausstellte, musste ich nicht wirklich jede einzelne Route auf dem Server rendern (nur wie 2), ich wollte Client-Ladezustände anstelle von Neuladen ganzer Seiten und ich wollte nicht den globalen Zustandsbaum zwischen Routenänderungen zerstören. Das, gepaart mit meiner Meinung, dass React-Router 4 das Beste seit geschnittenem Brot ist, bedeutete, dass Next.js nicht das Richtige für das Projekt war.

Auf der Suche nach etwas Stabilerem wechselte ich zum Kyt-Projekt von NYT. Dies war für etwa 2 Monate ausreichend, aber 1) die Build-Zeiten wurden wahnsinnig langsam (>45 s), als die App wuchs, 2) die SCSS-Regeln von kyt waren nicht die richtige Lösung für das Projekt, und 3) ich fand die Protokollierung von kyt (mit die wahnsinnige Menge an Emoji) ziemlich nervig. Also beschloss ich, an einem dünneren, schnelleren Ersatz für kyt zu arbeiten, aber mit universellem HMR und einer ähnlichen Konfigurations-API wie Next.js – sozusagen create-react-app-ssr .

Als alles gesagt und getan war, wurde mir klar, dass ich ein fast Framework-agnostisches Build-System erstellt hatte und dass diese Abstraktionsebene besser für die Anforderungen meines Projekts geeignet war. Mit "Framework-agnostisch" meine ich, dass Razzle zu 100 % mit Angular, Vue, Rax, Preact, Inferno, React-XP, RN-Web, Reason-React und, _am wichtigsten für mich_, was auch immer als nächstes verrücktes Zeug kommt, funktioniert. IMHO ist Anpassungsfähigkeit das Hauptunterscheidungsmerkmal zwischen Razzle und so ziemlich allem anderen, was ich gesehen habe. Mit Razzle können Sie etwas in einem Blogbeitrag lesen, einen Fork erstellen, ein Babel-Transform/Webpack-Konfigurations-/Parallel-Build-System hinzufügen und einfach loslegen und Scheiße ausprobieren . Warum? Denn im Gegensatz zu Next ist Razzle kein Framework und im Gegensatz zu CRA können Sie mit Razzle die zugrunde liegende Konfiguration erweitern, ohne sie zu forken. Das ist enorm für die Art und Weise, wie ich lerne, lehre, experimentiere und Geschäfte mache.

Razzles Flexibilität und Agnostizismus haben sich für mich und mein Team bereits ausgezahlt:

  • Wir haben unsere App schrittweise von teilweise Flow auf 100 % TypeScript umgestellt, indem wir weniger als 10 Codezeilen in razzle.config.js haben.
  • Ohne es überhaupt zu versuchen, ist Razzle der schnellste Weg, um ein ReasonReact-Projekt (SSR oder SPA) zu booten.

Was die Zukunft von Razzle betrifft. Vor zwei Tagen wurde „Hinzufügen von SSR-Unterstützung zu CRA“ als eine der Top-15-Todos auf der Roadmap des React Core-Teams erwähnt. Wenn SSR-Unterstützung zu CRA hinzugefügt wird, muss Razzle möglicherweise nicht mehr existieren ..._und ich bin total cool damit_. Bis dahin wird sich Razzle jedoch als Framework-agnostisches Build-Tool für vom Server gerendertes universelles JavaScript weiterentwickeln.

Alle 5 Kommentare

Ich denke, jeder würde zustimmen, dass die richtige Antwort wäre, dass dies davon abhängt, was Sie und Ihr neues Projekt brauchen.

Soweit ich weiß ist Next.js ein vollständiges Framework, das optional als Teil des ZEIT-Ökosystems verwendet werden kann? oder Plattform?. Während Razzle viel minimalistischer ist. Es enthält also keine Funktionen, die Sie möglicherweise nicht benötigen, aber es ist auch wahr, dass es keine Funktionen enthält, die Sie möglicherweise benötigen oder die Sie möglicherweise irgendwann benötigen werden.

Ich habe auch schon einmal darüber nachgedacht, Next.js zu verwenden, aber es gab einige kleine Details, die mich irritiert haben. Zum Beispiel minimiert Next.js die HTML-Ausgabe nicht richtig (ich weiß, dass das überhaupt nicht so wichtig ist, aber das war ein Deal Breaker für mich.). Es verwendet auch styled-jsx und CSS-in-JS, aber ich bevorzuge Styled Components . Außerdem brauchte ich für mein neues Projekt (noch 😄) kein Routing.

Schließlich und zum Glück habe ich nach dem Testen einer Reihe von Beispielprojekten Razzle gefunden und verwendet. Eigentlich habe ich damit begonnen, ein Beispielprojekt namens Razzle Material UI Styled Example zu erstellen, das einige Module und Funktionen enthält, die ich benötige. So kann ich jetzt fast schamlos an meinem neuen Projekt arbeiten. Fühlen Sie sich frei, das erwähnte Repository zu verwenden, wenn Sie dieselben Funktionen oder einige davon benötigen.

Danke @knipferrc

Eine ähnliche Erfahrung hat mich dazu gebracht, Razzle zu entwickeln.

Vor ungefähr 6 Monaten habe ich direkt nach dem Erscheinen eine riesige App mit Next.js gestartet, und die Abwanderung war zu groß für mich. Ich habe den PR für das parametrisierte Routing-Beispiel (dh /user/:id ) buchstäblich eingereicht. Ich erinnere mich, dass ich wegen eines seltsamen Fehlers im Zusammenhang mit dem Abfeuern von getInitialProps bei Routenänderungen eine ganze Woche Arbeit verloren habe . Am Ende des Tages trifft Next.js viele sehr wichtige Entscheidungen für Sie (z. B. Routing, Datenabruf, Ordnerstruktur und Styling). Ob diese gut oder schlecht sind, hängt ganz von der Art der Anwendung ab, die Sie erstellen. Wie sich herausstellte, musste ich nicht wirklich jede einzelne Route auf dem Server rendern (nur wie 2), ich wollte Client-Ladezustände anstelle von Neuladen ganzer Seiten und ich wollte nicht den globalen Zustandsbaum zwischen Routenänderungen zerstören. Das, gepaart mit meiner Meinung, dass React-Router 4 das Beste seit geschnittenem Brot ist, bedeutete, dass Next.js nicht das Richtige für das Projekt war.

Auf der Suche nach etwas Stabilerem wechselte ich zum Kyt-Projekt von NYT. Dies war für etwa 2 Monate ausreichend, aber 1) die Build-Zeiten wurden wahnsinnig langsam (>45 s), als die App wuchs, 2) die SCSS-Regeln von kyt waren nicht die richtige Lösung für das Projekt, und 3) ich fand die Protokollierung von kyt (mit die wahnsinnige Menge an Emoji) ziemlich nervig. Also beschloss ich, an einem dünneren, schnelleren Ersatz für kyt zu arbeiten, aber mit universellem HMR und einer ähnlichen Konfigurations-API wie Next.js – sozusagen create-react-app-ssr .

Als alles gesagt und getan war, wurde mir klar, dass ich ein fast Framework-agnostisches Build-System erstellt hatte und dass diese Abstraktionsebene besser für die Anforderungen meines Projekts geeignet war. Mit "Framework-agnostisch" meine ich, dass Razzle zu 100 % mit Angular, Vue, Rax, Preact, Inferno, React-XP, RN-Web, Reason-React und, _am wichtigsten für mich_, was auch immer als nächstes verrücktes Zeug kommt, funktioniert. IMHO ist Anpassungsfähigkeit das Hauptunterscheidungsmerkmal zwischen Razzle und so ziemlich allem anderen, was ich gesehen habe. Mit Razzle können Sie etwas in einem Blogbeitrag lesen, einen Fork erstellen, ein Babel-Transform/Webpack-Konfigurations-/Parallel-Build-System hinzufügen und einfach loslegen und Scheiße ausprobieren . Warum? Denn im Gegensatz zu Next ist Razzle kein Framework und im Gegensatz zu CRA können Sie mit Razzle die zugrunde liegende Konfiguration erweitern, ohne sie zu forken. Das ist enorm für die Art und Weise, wie ich lerne, lehre, experimentiere und Geschäfte mache.

Razzles Flexibilität und Agnostizismus haben sich für mich und mein Team bereits ausgezahlt:

  • Wir haben unsere App schrittweise von teilweise Flow auf 100 % TypeScript umgestellt, indem wir weniger als 10 Codezeilen in razzle.config.js haben.
  • Ohne es überhaupt zu versuchen, ist Razzle der schnellste Weg, um ein ReasonReact-Projekt (SSR oder SPA) zu booten.

Was die Zukunft von Razzle betrifft. Vor zwei Tagen wurde „Hinzufügen von SSR-Unterstützung zu CRA“ als eine der Top-15-Todos auf der Roadmap des React Core-Teams erwähnt. Wenn SSR-Unterstützung zu CRA hinzugefügt wird, muss Razzle möglicherweise nicht mehr existieren ..._und ich bin total cool damit_. Bis dahin wird sich Razzle jedoch als Framework-agnostisches Build-Tool für vom Server gerendertes universelles JavaScript weiterentwickeln.

Beeindruckend!! Vielen Dank Jungs für die tollen Antworten.

Hallo Jared, mir ist nicht ganz klar, wie ich Razzle verwenden soll, um ein SPA-Angular-Projekt in SSR zu konvertieren.
Kannst du mir bitte einen Tipp oder eine Anleitung geben, wie das geht? Ich danke dir sehr.

+1 für eine Razzle Angular-Lösung. https://github.com/jaredpalmer/razzle/issues/1109

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

kkarkos picture kkarkos  ·  3Kommentare

piersolenski picture piersolenski  ·  4Kommentare

Ronny25 picture Ronny25  ·  5Kommentare

JacopKane picture JacopKane  ·  3Kommentare

mhuggins picture mhuggins  ·  3Kommentare