Razzle: Démarrer une nouvelle application

Créé le 5 juin 2017  ·  5Commentaires  ·  Source: jaredpalmer/razzle

Ce projet a l'air génial. Je vais créer un nouveau projet et je me demandais simplement entre next.js, create-react-app et razzle, quels sont les avantages ou ce qui serait le mieux à long terme. J'aimerais vraiment SSR donc CRA est probablement hors de question. J'ai créé une application avec next, puis j'ai découvert ce projet. J'espère que c'est un bon endroit pour poser cette question, mais je voulais juste avoir quelques idées sur ce qui est le mieux à long terme.

discussion

Commentaire le plus utile

Merci @knipferrc

Une expérience similaire m'a amené à créer Razzle.

Il y a environ 6 mois, j'ai lancé une énorme application avec Next.js juste après sa sortie et le roulement était trop lourd à gérer pour moi. J'ai littéralement soumis le PR pour l'exemple de routage paramétré (c'est-à-dire /user/:id ). Je me souviens que j'ai perdu une semaine entière de travail à cause d'un bogue étrange lié au déclenchement de getInitialProps sur les changements de route . En fin de compte, Next.js prend pour vous de nombreuses décisions très importantes (c'est-à-dire le routage, la récupération des données, la structure des dossiers et le style). Que ce soit bon ou mauvais dépend entièrement du type d'application que vous construisez. Il s'est avéré que je n'avais pas réellement besoin de rendre chaque route sur le serveur (seulement comme 2), je voulais des états de chargement du client au lieu de rechargements de page complète, et je ne voulais pas détruire l'arbre d'état global entre les changements de route. Cela, couplé à mon opinion que React-Router 4 est la meilleure chose depuis le pain tranché, signifiait que Next.js n'était pas la bonne solution pour le projet.

À la recherche de quelque chose de plus stable, je suis passé au projet kyt du NYT. C'était suffisant pour environ ~ 2 mois, mais 1) les temps de construction sont devenus incroyablement lents (> 45 s) à mesure que l'application grandissait, 2) les règles SCSS de kyt n'étaient pas adaptées au projet, et 3) j'ai trouvé la journalisation de kyt (avec la quantité folle d'emoji) assez ennuyeux. J'ai donc décidé de commencer à travailler sur un remplacement plus fin et plus rapide pour kyt, mais avec HMR universel et une API de configuration similaire à Next.js-- create-react-app-ssr , pour ainsi dire.

Une fois que tout a été dit et fait, j'ai réalisé que j'avais créé un système de construction presque indépendant du framework et que ce niveau d'abstraction était plus adapté aux besoins de mon projet. Par "framework-agnostic", je veux dire que Razzle fonctionnera à 100% avec Angular, Vue, Rax, Preact, Inferno, React-XP, RN-Web, Reason-React et, _le plus important pour moi_, tout ce qui va suivre. À mon humble avis, l'adaptabilité est le principal différenciateur entre Razzle et à peu près tout ce que j'ai vu d'autre. Avec Razzle, vous pouvez lire quelque chose dans un article de blog, créer un fork, ajouter un système de construction babel-transform/webpack config/parallel et simplement essayer shit . Pourquoi? Parce que contrairement à Next, Razzle n'est pas un framework et contrairement à CRA, Razzle vous permet d'augmenter la configuration sous-jacente sans la forker. C'est énorme pour la façon dont j'apprends, enseigne, expérimente et fais des affaires.

La flexibilité et l'agnosticisme de Razzle ont déjà porté leurs fruits pour moi et mon équipe :

  • Nous avons progressivement déplacé notre application de partiellement Flow à 100 % TypeScript en modifiant moins de 10 lignes de code dans razzle.config.js .
  • Sans même essayer, Razzle est devenu le moyen le plus rapide de démarrer un projet ReasonReact (SSR ou SPA).

Quant à l'avenir de Razzle. Il y a deux jours, "l'ajout du support SSR à l'ARC" a été mentionné comme l'une des 15 principales tâches à effectuer sur la feuille de route de l'équipe React Core. Si le support SSR est ajouté à CRA, Razzle n'aura peut-être plus besoin d'exister... _et je suis totalement d'accord avec ça_. Jusqu'à ce que cela se produise, Razzle continuera d'être un outil de construction indépendant du framework pour le JavaScript universel rendu par le serveur.

Tous les 5 commentaires

Je pense que tout le monde serait d'accord sur le fait que la bonne réponse serait que cela dépend de ce dont vous et votre nouveau projet avez besoin.

Autant que je sache, Next.js est un framework complet qui peut éventuellement être utilisé dans le cadre de l'écosystème ZEIT ? ou plate-forme?. Alors que Razzle est beaucoup plus minimaliste. Il n'inclut donc pas les fonctionnalités dont vous n'avez peut-être pas besoin, mais il est également vrai qu'il n'inclut pas les fonctionnalités dont vous pourriez avoir besoin ou dont vous pourriez avoir besoin éventuellement.

J'ai également envisagé d'utiliser Next.js auparavant, mais il y avait quelques petits détails qui m'irritaient. Par exemple, Next.js ne minimise pas correctement la sortie HTML (je sais que ce n'est pas du tout important, mais c'était un facteur décisif pour moi.). Il utilise également styled-jsx et CSS-in-JS, mais je préfère Styled Components . De plus, pour mon nouveau projet, je n'ai pas eu besoin de routage (encore 😄).

Enfin et heureusement, après avoir testé un tas d'exemples de projets, j'ai fini par trouver et utiliser Razzle. En fait, j'ai commencé par créer un exemple de projet appelé Razzle Material UI Styled Example comprenant certains modules et fonctionnalités dont j'ai besoin. Alors maintenant, je peux travailler sur mon nouveau projet presque sans vergogne. N'hésitez pas à utiliser le référentiel mentionné si vous avez besoin des mêmes fonctionnalités ou de certaines d'entre elles.

Merci @knipferrc

Une expérience similaire m'a amené à créer Razzle.

Il y a environ 6 mois, j'ai lancé une énorme application avec Next.js juste après sa sortie et le roulement était trop lourd à gérer pour moi. J'ai littéralement soumis le PR pour l'exemple de routage paramétré (c'est-à-dire /user/:id ). Je me souviens que j'ai perdu une semaine entière de travail à cause d'un bogue étrange lié au déclenchement de getInitialProps sur les changements de route . En fin de compte, Next.js prend pour vous de nombreuses décisions très importantes (c'est-à-dire le routage, la récupération des données, la structure des dossiers et le style). Que ce soit bon ou mauvais dépend entièrement du type d'application que vous construisez. Il s'est avéré que je n'avais pas réellement besoin de rendre chaque route sur le serveur (seulement comme 2), je voulais des états de chargement du client au lieu de rechargements de page complète, et je ne voulais pas détruire l'arbre d'état global entre les changements de route. Cela, couplé à mon opinion que React-Router 4 est la meilleure chose depuis le pain tranché, signifiait que Next.js n'était pas la bonne solution pour le projet.

À la recherche de quelque chose de plus stable, je suis passé au projet kyt du NYT. C'était suffisant pour environ ~ 2 mois, mais 1) les temps de construction sont devenus incroyablement lents (> 45 s) à mesure que l'application grandissait, 2) les règles SCSS de kyt n'étaient pas adaptées au projet, et 3) j'ai trouvé la journalisation de kyt (avec la quantité folle d'emoji) assez ennuyeux. J'ai donc décidé de commencer à travailler sur un remplacement plus fin et plus rapide pour kyt, mais avec HMR universel et une API de configuration similaire à Next.js-- create-react-app-ssr , pour ainsi dire.

Une fois que tout a été dit et fait, j'ai réalisé que j'avais créé un système de construction presque indépendant du framework et que ce niveau d'abstraction était plus adapté aux besoins de mon projet. Par "framework-agnostic", je veux dire que Razzle fonctionnera à 100% avec Angular, Vue, Rax, Preact, Inferno, React-XP, RN-Web, Reason-React et, _le plus important pour moi_, tout ce qui va suivre. À mon humble avis, l'adaptabilité est le principal différenciateur entre Razzle et à peu près tout ce que j'ai vu d'autre. Avec Razzle, vous pouvez lire quelque chose dans un article de blog, créer un fork, ajouter un système de construction babel-transform/webpack config/parallel et simplement essayer shit . Pourquoi? Parce que contrairement à Next, Razzle n'est pas un framework et contrairement à CRA, Razzle vous permet d'augmenter la configuration sous-jacente sans la forker. C'est énorme pour la façon dont j'apprends, enseigne, expérimente et fais des affaires.

La flexibilité et l'agnosticisme de Razzle ont déjà porté leurs fruits pour moi et mon équipe :

  • Nous avons progressivement déplacé notre application de partiellement Flow à 100 % TypeScript en modifiant moins de 10 lignes de code dans razzle.config.js .
  • Sans même essayer, Razzle est devenu le moyen le plus rapide de démarrer un projet ReasonReact (SSR ou SPA).

Quant à l'avenir de Razzle. Il y a deux jours, "l'ajout du support SSR à l'ARC" a été mentionné comme l'une des 15 principales tâches à effectuer sur la feuille de route de l'équipe React Core. Si le support SSR est ajouté à CRA, Razzle n'aura peut-être plus besoin d'exister... _et je suis totalement d'accord avec ça_. Jusqu'à ce que cela se produise, Razzle continuera d'être un outil de construction indépendant du framework pour le JavaScript universel rendu par le serveur.

Wow!! Merci beaucoup les gars pour les réponses géniales.

Salut Jared, je ne sais pas très bien comment utiliser Razzle pour convertir un projet SPA Angular en SSR.
Pouvez-vous s'il vous plaît me donner un indice ou un guide sur la façon de le faire? Merci beaucoup.

+1 pour une solution Razzle Angular. https://github.com/jaredpalmer/razzle/issues/1109

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

dizzyn picture dizzyn  ·  3Commentaires

panbanda picture panbanda  ·  5Commentaires

krazyjakee picture krazyjakee  ·  3Commentaires

piersolenski picture piersolenski  ·  4Commentaires

jcblw picture jcblw  ·  4Commentaires