Which one to learn?

I compared how both handled a simple form and React looks awfully shitty and moronic, but there are few job offers for Vue in my country (France)

Thalidomide Vintage Ad Shirt $22.14

Shopping Cart Returner Shirt $21.68

Thalidomide Vintage Ad Shirt $22.14

  1. 2 years ago
    Anonymous

    kill your self webshitter

    • 2 years ago
      Anonymous

      Seethe

      • 2 years ago
        Anonymous

        Learn both! If React is what it takes to get you a job, learn React. If you want to then use Vue in your personal projects (or have it in your skillset when transferring jobs), go ahead and learn Vue as well. As a developer, you have to be constantly learning new technologies anyways. Don't just learn one thing that you need for your job and feel like you're comfortable and can stop learning.

        As a PhD student, this image made me laugh a bit. Though strictly speaking, I am almost never in the lab. When covid pushed everyone to working from home, I just... stayed working from home. Also, I don't eat in the dining commons. Anyone who does is an absolute moron who doesn't know how to manage their money, and somehow managed to make it to adulthood without learning how to cook.

    • 2 years ago
      Anonymous

      fpbp
      Go shit somewhere OP. you have 20 more framework to learn and hundreds of thousands of lines of cope just to print "hello world!" without side effects because your language is shit.

      • 2 years ago
        Anonymous

        >hundreds of thousands of lines of cope just to print "hello world!" without side effects because your language is shit.
        >thousands of lines
        console.log("hello homosexual, seethe harder");

        • 2 years ago
          Anonymous

          >prints in console
          >i did it reddit!!!
          >forgets he had to install node and has hundreds of thousands of folders and rely heavily on the cli
          >his hello world programs takes hundreds of thousands of years to copy from disk

        • 2 years ago
          Anonymous

          nice try homosexual.

          • 2 years ago
            Anonymous

            What a disgusting language, do front end dev really have to deal with this shit everyday ?

          • 2 years ago
            Anonymous

            No, since it's not framework code

          • 2 years ago
            Anonymous

            Or it is actually, what is that abomination

          • 2 years ago
            Anonymous

            document.body.innerHTML = "<h1>Hello, World!</h1>";

          • 2 years ago
            Anonymous

            >LOGGED IN ON GAYGLE GROME
            pls die

  2. 2 years ago
    Anonymous

    Then learn Vue, why you gotta make your own shitty fricking thread for this instead of asking your moron question in wdg or sqt?

  3. 2 years ago
    Anonymous

    make your workplace switch to vue

  4. 2 years ago
    Anonymous

    Après avoir acquis les notions de bases en JS j'ai misé sur Vue. J'ai parié que le framework allait rafler assez de parts de marché et j'ai perdu ce pari. ça m'étonnerai de voir Vue décoller et le framework a perdu l'avantage compétitif qu'il avait à cause de Svelte et SolidJS. Je me suis finalement résigné à apprendre React/Nextjs/Redux pour le front et Spring pour le backend parceque ce sont les framework les plus utilisés dans mon pays (Maroc). Utilise Vue pour tes projets persos et maitrise React pour devenir employable. Comme ça, tu pourra postuler pour les deux, et si jamais tu as de la chance, tu pourra travailler dans une agence ou une startup qui utilise Vue. Autrement, tu feras comme tout le monde et intégrera une team qui utilise React.

    • 2 years ago
      Anonymous

      Omelette du fromage

      • 2 years ago
        Anonymous

        >Omelette au* fromage

        • 2 years ago
          Anonymous

          No.. no I don't think so

    • 2 years ago
      Anonymous

      If you have to use one or the other, choose Vue. React is utterly trash, especially the hooks part. For anything else, use vanilla.

      For english press 1

      • 2 years ago
        Anonymous

        >If you have to use one or the other, choose Vue. React is utterly trash, especially the hooks part. For anything else, use vanilla.
        That's only true if he isn't searching for a job tho or is already a CS / SWE graduate.

    • 2 years ago
      Anonymous

      Merci pour ton retour 🙂 je pense que je vais faire ça.

      • 2 years ago
        Anonymous

        Bon courage!
        ça serait utile d'apprendre un peu de backend également. Next.js est un framework fullstack qui te permet de créer ton frontend avec React et ton backend avec Node/Express. Certaines PME et Startup n'ont pas les ressources pour employer des spécialistes. Ils cherchent des devs avec un niveau correct/passable aussi bien en backend qu'en front qui sont mis sous la supervision de managers plus expérimentés. Et puis comme ça, tu ne tomberas pas dans l'inévitable burnout de devoir utiliser la même technologie tous les jours.

        PS: l'équivalent de Next pour Vue s'appelle "Nuxt".

        • 2 years ago
          Anonymous

          Next.js utilise Express ? Je comprends pas trop à quoi ce framework sert

          Mais oui j'ai déjà vu un peu de back et fait un serveur en Express
          Mais j'utilisais EJS pour rendre mes views

          • 2 years ago
            Anonymous

            En gros, Next.js est un framework SSR (server side rendering). Tu crées un serveur next qui génère tes pages (frontend) à l'ancienne. Tu peux choisir de créer des SPA, des MPA ou des sites hybrides qui combinent SPA & MPA (eg. différentes pages pour l'accueil, le pricing, la présentation des services, etc.. mais une SPA pour l'application SAAS une fois que l'utilisateur est connecté). ça représente un gain en performance et un gain en SEO indéniable. Pour ce qui est du backend, oui, NEXT offre la possibilité d'utiliser Express. Donc tu peux créer une application fullstack avec ce framework seul. Penses Django ou Laravel avec leur templating engine (que personne n'utilise). Maintenant remplace le templating engine avec React. Pour les plus pebreasts projets, même la base de donnée relationnelle peut être intégrée au framework en utilisant SQLite & Prisma (ORM) bien que ce ne soit pas quelque chose que je recommande.

          • 2 years ago
            Anonymous

            Je vois merci ! En gros est un framework front pour faire un projet complet avec du front en react si je comprends bien

            Oui j'utilisais EJS pour le templating mais bon faut que j'apprenne React pour choper un job

            Tu déconseilles les ORM ?

            La grosse différence étant que Next ne présente pas de documents JSON/Javascript au navigateur mais des pages HTML à l'ancienne. Si les pages sont statiques, il utilise du SSG (Static Site Generation) pour transformer ton JSX en HTML côté serveur. Le navigateur reçoit un document analysable correctement par les bots Google (meilleur SEO) et le temps de latence est réduit au minimum.

            React présente un doc JS au client ? Je croyais qu'il envoyait une page html avec tout le js babélisé pour génerer les différentes pages coté client

            Pas compris pourquoi le SSR avait un avantage en SEO ? Je vois tout le monde dire ça

            Et concrètement les SPA c'est de la merde non ? Je veux dire, tous les exemples de SPA que je connais (Gmail, Uber Eats...) rament à mort, faut toujours attendre un temps de loading dès que tu cliques sur une page

            C'est beaucoup moins rapide qu'un simple site en SSR avec un petit templating à la EJS, je comprends pas pourquoi on s'emmerde avec React

          • 2 years ago
            Anonymous

            >En gros est un framework front pour faire un projet complet avec du front en react si je comprends bien
            En gros Next est un framework pour faire un projet complet (donc aussi le back) avec un front en react si je comprends bien*

          • 2 years ago
            Anonymous

            react is based, just make sure to use hooks

            La grosse différence étant que Next ne présente pas de documents JSON/Javascript au navigateur mais des pages HTML à l'ancienne. Si les pages sont statiques, il utilise du SSG (Static Site Generation) pour transformer ton JSX en HTML côté serveur. Le navigateur reçoit un document analysable correctement par les bots Google (meilleur SEO) et le temps de latence est réduit au minimum.

            Next.js utilise Express ? Je comprends pas trop à quoi ce framework sert

            Mais oui j'ai déjà vu un peu de back et fait un serveur en Express
            Mais j'utilisais EJS pour rendre mes views

            Bon courage!
            ça serait utile d'apprendre un peu de backend également. Next.js est un framework fullstack qui te permet de créer ton frontend avec React et ton backend avec Node/Express. Certaines PME et Startup n'ont pas les ressources pour employer des spécialistes. Ils cherchent des devs avec un niveau correct/passable aussi bien en backend qu'en front qui sont mis sous la supervision de managers plus expérimentés. Et puis comme ça, tu ne tomberas pas dans l'inévitable burnout de devoir utiliser la même technologie tous les jours.

            PS: l'équivalent de Next pour Vue s'appelle "Nuxt".

            Merci pour ton retour 🙂 je pense que je vais faire ça.

            Après avoir acquis les notions de bases en JS j'ai misé sur Vue. J'ai parié que le framework allait rafler assez de parts de marché et j'ai perdu ce pari. ça m'étonnerai de voir Vue décoller et le framework a perdu l'avantage compétitif qu'il avait à cause de Svelte et SolidJS. Je me suis finalement résigné à apprendre React/Nextjs/Redux pour le front et Spring pour le backend parceque ce sont les framework les plus utilisés dans mon pays (Maroc). Utilise Vue pour tes projets persos et maitrise React pour devenir employable. Comme ça, tu pourra postuler pour les deux, et si jamais tu as de la chance, tu pourra travailler dans une agence ou une startup qui utilise Vue. Autrement, tu feras comme tout le monde et intégrera une team qui utilise React.

            pic rel, frog eating homosexuals

          • 2 years ago
            Anonymous

            You are probably that moron that never returns a clean up from his effects and haven't used AbortController once in your life

          • 2 years ago
            Anonymous

            in English, doc

          • 2 years ago
            Anonymous

            >Et concrètement les SPA c'est de la merde non ?
            Oui et non. Pour un site ecommerce par exemple, le SPA est horrible. Tu as des milliers de pages. Imagine un peu un site qui génère toutes ces pages en une fois. Aussi, tu as envie d'optimiser ton SEO pour chaque produit et chaque catégorie. Bonne chance avec ça si tu utilises un framework SPA.
            Maintenant imagine que tu possède une application web en SAAS. Tu as ton showcase website qui contient ta page d'accueil, ta documentation, ton pricing, la présentation de tes services, ect... et tu as envie que cette partie soit générée sous forme de MPA, que le SEO soit optimisé et que le rendu initial soit rapide. Mais tu as aussi ton application (intranet) pour les utilisateurs connectés derrière des guarded routes. Cette partie devrait de préférence être sous la forme de SPA puisqu'il s'agit d'une application (avec un fonctionnement similaire aux applications natives sur mobile et desktop). Une fois que l'utilisateur se connecte, un loader (ou splash screen) lui est présenté en attendant que le contenu soit chargé, et une fois que c'est fait, il n'a plus à faire des requêtes pour chaque page/component qu'il essaye de charger. Son application est servie et il peut l'utliliser. Les seules requêtes restantes sont pour des opérations de type CRUD avec ton serveur.

          • 2 years ago
            Anonymous

            Je vois...
            Merci ^^

          • 2 years ago
            Anonymous

            Mais du coup hors ces besoins précis (webapp etc), pour la plupart des sites classiques (ecommerce, forum, site d'entreprise, blog, portfolio, etc), tu t'en sortirais mieux avec du SSR à la Ejs qu'en foutant du React en front non ?

          • 2 years ago
            Anonymous

            Exactement oui. Tu as raison. Tu peux aussi utiliser Vue à la place de EJS si tu préfères. Vue peut être utilisé un peu comme EJS et JQuery. Tu n'as pas besoin de créer un projet Vue. Tu peux juste l'intégrer à un document HTML et l'utiliser là où tu le sens adapté.

          • 2 years ago
            Anonymous

            La grosse différence étant que Next ne présente pas de documents JSON/Javascript au navigateur mais des pages HTML à l'ancienne. Si les pages sont statiques, il utilise du SSG (Static Site Generation) pour transformer ton JSX en HTML côté serveur. Le navigateur reçoit un document analysable correctement par les bots Google (meilleur SEO) et le temps de latence est réduit au minimum.

          • 2 years ago
            Anonymous

            If you guys were speaking spanish or hindi gtards woukd throw a fit.

  5. 2 years ago
    Anonymous

    if you want job opportunities, just learn react and do the common practices even though they're all stupid. Atleast you have a job and you know a widely used framework.

    React is my least favourite thing about javascript but it gets the job done and is used by most meaning i get jobs so unfortunately... I use react.

    If you want to make your own thing or if your job gives you options, then use something else 100%.

  6. 2 years ago
    Anonymous

    > few job offers for Vue
    then learn React and have react projects in your github profile. The framework doesnt matter, learning JavaScript doesnt matter. Be comfortable with both. I dont wanna hire React engineers, i wanna hire people to solve my problems

  7. 2 years ago
    Anonymous

    Just use alpinejs and htmx

  8. 2 years ago
    Anonymous

    Vue is easier to get your head around but apparently sperged out with the latest version and not as widely used. React is more widely used, better job prospects, maintained by facebook but more of a learning curve I guess. In summary I'd read up on both but probably focus more on react.

  9. 2 years ago
    Anonymous

    sacre putain de ta mere c'est encule

  10. 2 years ago
    Anonymous

    No point in talking about which framework will get you the job since that ship has sailed.
    What you should be asking is which is the most lightweight, easy to use and has the most feautures.
    Which is... which one is that?

    • 2 years ago
      Anonymous

      >JavaScript
      >lightweight

      • 2 years ago
        Anonymous

        js files are pretty lightweight...

  11. 2 years ago
    Anonymous

    svelte

  12. 2 years ago
    Anonymous

    React is already deprecated legacy trash we all moved to flutter.

    • 2 years ago
      Anonymous

      >flutter
      kek

      >unstable
      >bloated
      >10000+ issues on github

      https://github.com/flutter/flutter/issues

      • 2 years ago
        Anonymous

        >10000 open issues
        >60000 total issues
        holy shit, how is it such a shit show?

    • 2 years ago
      Anonymous

      For desktops and mobile apps i might agree (Flutter is objectively better than React Native and Electron). On the web, Flutter is horrible. Really, really horrible. Even for small apps, there is a clear, noticeable, massive performance loss when compared to React (let alone raw JS). The only usable WASM Frameworks are Blazor and Rust.

  13. 2 years ago
    Anonymous

    In Germany BW I've seen more Angular job openings than for React or Vue so far.

  14. 2 years ago
    Anonymous

    >React looks awfully shitty and moronic

    React is about function, not design. It's used to build components that you assemble into other components. If you don't add styling, it should look indistinguishable from a plain HTML page.

    That said, it's super powerful for large websites that can end up hundreds of divs deep. So of course, to use it to make small websites and demos, it feels like mobilizing an entire CNC factory to manufacture a wooden spoon when a hand chisel and hammer would've worked.

    • 2 years ago
      Anonymous

      Compare all the crap React requires to manage a simple form vs the method Vue uses

      • 2 years ago
        Anonymous

        What are you on about?
        function login(data) {
        console.log(data);
        }

        export default function App() {
        function handleSubmit(e) {
        e.preventDefault();
        const form = e.target;
        const formData = new FormData(form);

        login({
        username: formData.get('username'),
        password: formData.get('password'),
        });
        }

        return (
        <div className="App">
        <form onSubmit={handleSubmit}>
        <input type="text" name="username" placeholder="Username" required />
        <input
        type="password"
        name="password"
        placeholder="Password"
        required
        />
        <button type="submit">Log In</button>
        </form>
        </div>
        );
        }

        Aside from JSX, this is plain JavaScript, no stupid made up APIs you have to conform to and forget once you switch technology.

        • 2 years ago
          Anonymous

          based react chad putting vue prostitutes in their place

        • 2 years ago
          Anonymous

          based react chad putting vue prostitutes in their place

          https://medium.com/swlh/react-vs-vue-handling-form-input-ea661f11316b

          • 2 years ago
            Anonymous

            >storing input values in state
            Yeah... this guy has no clue on how to use React.

          • 2 years ago
            Anonymous

            React escapes input values so no problem
            Noob

          • 2 years ago
            Anonymous

            What does that have to do with escaping? I can't tell if you're baiting or serious

          • 2 years ago
            Anonymous

            What's wrong with what he's doing then?

          • 2 years ago
            Anonymous

            Pointlessly using state to store the input values, when they you can easily extract them via the FormData API, as seen here

            What are you on about?
            function login(data) {
            console.log(data);
            }

            export default function App() {
            function handleSubmit(e) {
            e.preventDefault();
            const form = e.target;
            const formData = new FormData(form);

            login({
            username: formData.get('username'),
            password: formData.get('password'),
            });
            }

            return (
            <div className="App">
            <form onSubmit={handleSubmit}>
            <input type="text" name="username" placeholder="Username" required />
            <input
            type="password"
            name="password"
            placeholder="Password"
            required
            />
            <button type="submit">Log In</button>
            </form>
            </div>
            );
            }

            Aside from JSX, this is plain JavaScript, no stupid made up APIs you have to conform to and forget once you switch technology.

            Creating a new FormData object and passing a Form element to it will create a mapping between input names and their values. This is a Standard Web API - Not unique to React.

  15. 2 years ago
    Anonymous

    https://fullstackopen.com/en/

    • 2 years ago
      Anonymous

      you're not supposed to spoonfeed them, moron

      • 2 years ago
        Anonymous

        frick you

    • 2 years ago
      Anonymous

      Wow! So this is the power of webshitting! Impressive.

  16. 2 years ago
    Anonymous

    [...]

    Merci beaucoup pour tes réponses détaillées !

    Je vois merci ! En gros est un framework front pour faire un projet complet avec du front en react si je comprends bien

    Oui j'utilisais EJS pour le templating mais bon faut que j'apprenne React pour choper un job

    Tu déconseilles les ORM ?

    [...]
    React présente un doc JS au client ? Je croyais qu'il envoyait une page html avec tout le js babélisé pour génerer les différentes pages coté client

    Pas compris pourquoi le SSR avait un avantage en SEO ? Je vois tout le monde dire ça

    Et concrètement les SPA c'est de la merde non ? Je veux dire, tous les exemples de SPA que je connais (Gmail, Uber Eats...) rament à mort, faut toujours attendre un temps de loading dès que tu cliques sur une page

    C'est beaucoup moins rapide qu'un simple site en SSR avec un petit templating à la EJS, je comprends pas pourquoi on s'emmerde avec React

    >Et concrètement les SPA c'est de la merde non ? Je veux dire, tous les exemples de SPA que je connais (Gmail, Uber Eats...) rament à mort, faut toujours attendre un temps de loading dès que tu cliques sur une page
    >C'est beaucoup moins rapide qu'un simple site en SSR avec un petit templating à la EJS, je comprends pas pourquoi on s'emmerde avec React
    Ton avis perso sur ça ?

    • 2 years ago
      Anonymous

      >Ton avis perso sur ça ?
      Le voici:

      >Et concrètement les SPA c'est de la merde non ?
      Oui et non. Pour un site ecommerce par exemple, le SPA est horrible. Tu as des milliers de pages. Imagine un peu un site qui génère toutes ces pages en une fois. Aussi, tu as envie d'optimiser ton SEO pour chaque produit et chaque catégorie. Bonne chance avec ça si tu utilises un framework SPA.
      Maintenant imagine que tu possède une application web en SAAS. Tu as ton showcase website qui contient ta page d'accueil, ta documentation, ton pricing, la présentation de tes services, ect... et tu as envie que cette partie soit générée sous forme de MPA, que le SEO soit optimisé et que le rendu initial soit rapide. Mais tu as aussi ton application (intranet) pour les utilisateurs connectés derrière des guarded routes. Cette partie devrait de préférence être sous la forme de SPA puisqu'il s'agit d'une application (avec un fonctionnement similaire aux applications natives sur mobile et desktop). Une fois que l'utilisateur se connecte, un loader (ou splash screen) lui est présenté en attendant que le contenu soit chargé, et une fois que c'est fait, il n'a plus à faire des requêtes pour chaque page/component qu'il essaye de charger. Son application est servie et il peut l'utliliser. Les seules requêtes restantes sont pour des opérations de type CRUD avec ton serveur.

      >Merci beaucoup pour tes réponses détaillées !
      Je t'en prie, ça me fait plaisir aussi.

    • 2 years ago
      Anonymous

      >Et concrètement les SPA c'est de la merde non ?
      Oui et non. Pour un site ecommerce par exemple, le SPA est horrible. Tu as des milliers de pages. Imagine un peu un site qui génère toutes ces pages en une fois. Aussi, tu as envie d'optimiser ton SEO pour chaque produit et chaque catégorie. Bonne chance avec ça si tu utilises un framework SPA.
      Maintenant imagine que tu possède une application web en SAAS. Tu as ton showcase website qui contient ta page d'accueil, ta documentation, ton pricing, la présentation de tes services, ect... et tu as envie que cette partie soit générée sous forme de MPA, que le SEO soit optimisé et que le rendu initial soit rapide. Mais tu as aussi ton application (intranet) pour les utilisateurs connectés derrière des guarded routes. Cette partie devrait de préférence être sous la forme de SPA puisqu'il s'agit d'une application (avec un fonctionnement similaire aux applications natives sur mobile et desktop). Une fois que l'utilisateur se connecte, un loader (ou splash screen) lui est présenté en attendant que le contenu soit chargé, et une fois que c'est fait, il n'a plus à faire des requêtes pour chaque page/component qu'il essaye de charger. Son application est servie et il peut l'utliliser. Les seules requêtes restantes sont pour des opérations de type CRUD avec ton serveur.

      C'est pourquoi -à moins de créer ton framework customisé en raw JS-, des outils comme Next ou Remix sont une solution à 90% du problème. Tu choisis quelles parties de ton site sont en SPA et lesquelles sont en MPA. Les pages statiques sont optimisées le mieux possible grâce à la technologie SSG. Et si tu as un intranet sous forme d'application (penses quelque chose comme Discord), tu peux la livrer sous forme de SPA. Pour ce qui est de l'idée qu'un SPA est toujours mauvais, je ne pense pas qu'elle soit juste. Imagine utiliser Discord et devoir recharger/créer une nouvelle page à chaque bouton cliqué, à chaque serveur discord consulté et à chaque contact auquel tu accèdes.

      • 2 years ago
        Anonymous

        Je vois... Oui vu comme ça je comprends enfin l'intérêt de ces frameworks
        Apres en théorie tu pourrais faire une webapp à la Discord sans React avec de l'ajax/asynchrone/du websocket pour changer les données de façon réactive non ?

        • 2 years ago
          Anonymous

          En théorie oui. En pratique, j'ai des doutes par rapport à la lisibilité, et à ta capacité à maintenir une application de la sorte. La meilleure approche (ce que tu finiras par faire de toute façon), serait de créer un framework sur mesure en Javascript. C'est ce que Youtube et Amazon font d'ailleurs. A défaut d'utiliser les frameworks JS disponibles au grand public, ces derniers ont créé des frameworks sur-mesure pour leurs besoins internes.

          Un autre point important à garder à l'esprit. Ce n'est jamais React en soit qui rend un site comme Spotify si lent. Si tu ouvres le Chrome dev tools et que tu jettes un coup d'oeil aux scripts chargés, tu verras que c'est essentiellement les scripts de tracking qui rendent les sites affreusement lents. La tendance de nombreux devs et d'agences de developement à intégrer des dizaines et des dizaines de librairies inutiles jouent un rôle majeur là dedans. Tu devrais jetter un coup d'oeil aux benchmarks de certaines librairies de slider/caroussels. C'est délirant, et pourtant, ces fonctionnalités peuvent être très facilement ajoutées avec du simple CSS (pas besoin de toucher à Javascript).

          • 2 years ago
            Anonymous

            Le pire c'est le site d'Uber Eats en la matière.
            Du coup, un dashboard admin c'est un parfait exemple de chose où une SPA peut être pertinente non ? Pas beaucoup de pages, pas besoin de SEO...

          • 2 years ago
            Anonymous

            >Du coup, un dashboard admin c'est un parfait exemple de chose où une SPA peut être pertinente non ? Pas beaucoup de pages, pas besoin de SEO...
            Tu as parfaitement compris. Un dashboard admin ou une application interne (eg. l'intranet de ton école ou ta fac) sont de parfaits exemples.

            >Le pire c'est le site d'Uber Eats en la matière.
            C'est un excellent cas d'étude, en effet. Le site génère des centaines de trackers. Certains sont simples et envoient le user-agent à une base de données, d'autres sont horribles et vont créer des heatmap en se basant sur les mouvements de ta souris sur l'écran en temps réel. Ce qu'il y a de pire, ce sont les sites qui usent et abusent d'animations en Javascript qu'ils implémentent via des librairies mal codées alors que la majorité de ces animations sont complètement inutiles, affectent l'UX et peuvent être très simplement implémentées avec du CSS

          • 2 years ago
            Anonymous

            J'avais lu un dev avancé dire que maintenant le back se résumait a faire une API, tu es d'accord ?
            Je comprends pas trop pourquoi
            Pour avoir un endpoint que ton front en react côté client peut contacter ?
            Mais du coup n'importe qui peut contacter tes routes :/

            Faut que je creuse le sujet, c'est vrai que si du coup ton front est géré côté client j'imagine qu'il faut faire une API pour interagir avec tu gères pas ça en interne comme en SSR

          • 2 years ago
            Anonymous

            >J'avais lu un dev avancé dire que maintenant le back se résumait a faire une API, tu es d'accord ?
            Dans 90% des applications et des programmes qui existent, c'est la base de donnée qui représente la partie la plus importante. Le backend a toujours été essentiellement des opérations de type CRUD avec un input, des modifications qui sont apportées côté serveur, et un output vers la base de donnée et vice versa. La logique et la fonctionnalité réelle de ton application est là.

            Imagine une application qui se charge de la gestion d'inventaire. Il y aura un modèle de base donnée qui définira un schéma pour structurer les relations entre les produits, catégories, livraisons, commandes, espaces de stockages, etc... Il y aura de la logique pour calculer la TVA et les promos, etc... Il y aura un générateur de facture et de devis qui capture des données récemment créées et qui utilise du HTML/CSS pour créer un document PDF où tout cela sera inséré. Il y aura un service d'envoi d'email automatisés lorsqu'un trigger est actionné qui prendra des données créées dans la base de donnée, les intégrera dans des balises HTML et les enverra au client.

            La partie DATA est le coeur de ton application. Un programme est un système qui prend de la donnée, la transforme, la stocke et la sert, tout simplement. Un réseau social fonctionne de la même manière. Maintenant, il y a certaines applications où le côté transformation de la donnée est plus alambiqué et complexe. Ce sont les programmes qui reposent sur le machine learning ou du deep learning. Mais encore une fois, là aussi, la donnée est plus importante que l'algorithme en soit. Un programme d'intelligence artificiel repose davantage sur la quantité de données et le nombre de paramètres qu'il doit analyser que par la qualité de l'algorithme.

      • 2 years ago
        Anonymous

        >Les pages statiques sont optimisées le mieux possible grâce à la technologie SSG.
        C'est quoi la différence avec du SSR ?
        Le SSG sert juste des fichiers statiques sans rendu dynamique de valeur ? Un peu comme le dossier static public dans Node ?

        • 2 years ago
          Anonymous

          Exactement. Ce qui est généralement le cas pour tes pages d'accueil, de pricing, de présentation de services, etc... NextJS crée les pages en question (tout comme le reste de ton application web) en React, mais les transforme en HTML entièrement statique côté serveur et les sert au client comme tu le ferais avec EJS ou en PHP.

          • 2 years ago
            Anonymous

            Je vois je vois. Heureusement que je t'ai parlé, le lien que j'avais lu sur Next disait que ça servait uniquement à faire du SSR/SSG ^^

            Du coup, c'est quoi le plus utilisé sur le marché de l'emploi pour du SSR ? Parce que je vois EJS nul part dans les offres d'emploi, on dirait que tout le monde veut son front en React par chez moi...

          • 2 years ago
            Anonymous

            EJS n'est pas utilisé, tout simplement. Next a une très très forte croissance et je crois bien qu'il finira par supplanter le vieux standard SPA et l'utilisation de React en SSR. Il offre plus de flexibilité, de performance, et une meilleure optimisation SEO.

            Si tu veux faire du SSR sans frameworks Javascript tu vas devoir te concentrer davantage sur le backend, et par là, je veux dire apprendre un language dédié backend à la place de Node.js qui est surtout utilisé pour les applications orientées client. Java, Kotlin, Go et C# sont les meilleurs exemples. C# avec du ASP.NET Core offre un templating engine (qui est bien plus populaire que EJS) et qui se nomme Razor. Il y a également un outil pour remplacer Javascript avec du C# en exploitant WASM qui se nomme Blazor. Go a aussi un outil qui se nomme GopherJS mais il n'est pas aussi utilisé. Ce sont surtout les agences de développement et les entreprises qui utilisent du C# qui ont tendance à utiliser des templating engines ou WASM plus fréquement.

          • 2 years ago
            Anonymous

            >Next a une très très forte croissance et je crois bien qu'il finira par supplanter le vieux standard SPA
            Tu veux dire avec son approche SSR/SSG à la place ? Parce qu'apparemment c'est dur de mettre en place une SPA dessus https://colinhacks.com/essays/building-a-spa-with-nextjs

            Mais du coup comment Next gère les endroits ou tu as besoin de donnees vraiment reactives sans reload ?

          • 2 years ago
            Anonymous

            Ah et maintenant que j'ai sous la main quelqu'un qui explique bien, j'aimerais savoir si j'ai bien compris à quoi sert webpack et tous les bundlers du genre : on est d'accord que c'est seulement utile avec les trucs comme React etc où tu te retrouves avec un fichier js par composant et des relations entre les fichiers dans tous les sens ? Du coup ca sert juste à reconstituer le tout dans un gros fichier js servi dans la page html envoyée au début par la SPA ?

            En dehors de React etc et d'une SPA, pas vraiment d'intérêt, si ?

            Et Babel transforme juste le JSX en JS compatible avec les vieux navigateurs

          • 2 years ago
            Anonymous

            Je dois sortir vite fait mais je serai de retour dans pas longtemps. Tu peux me poser tes autres questions en attendant et je répondrai à tout à mon retour.

          • 2 years ago
            Anonymous

            J'arrête la salve de questions là ^^ merci beaucoup d'avoir pris le temps

  17. 2 years ago
    Anonymous

    Return the computer, Jamal

  18. 2 years ago
    Anonymous

    Seems to me like preact is the best one for personal projects and react for corpohomosexualry.
    I don't get the vue hype.

    • 2 years ago
      Anonymous
      • 2 years ago
        Anonymous

        Its just 42 milliseconds more or whatever significant amount

  19. 2 years ago
    Anonymous

    >still using js in 2022 instead of webassembly
    frontend dev are lazy bastards

    • 2 years ago
      Anonymous

      webassembly is not designed to replace javascript

  20. 2 years ago
    Anonymous

    Vue is for people who can't be bothered to learn React. I've worked with both and React is far better if you actually get the ins and out of basic hooks and libraries (formik, query, redux toolkit), know how to make your own hooks and also understand JSX in-depth.

    Vue is not bad, but it's a bit like a toy compared to React. React is also somewhat a toy compared to Angular so there's that.

  21. 2 years ago
    Anonymous

    I love VUE <3

  22. 2 years ago
    Anonymous

    >but there are few job offers for Vue
    That is a good thing, it means you will have less competence.

    • 2 years ago
      Anonymous

      >less competence
      How is the weather in India pajeet?

    • 2 years ago
      Anonymous

      What?

  23. 2 years ago
    Anonymous

    React will get you a job, but Vue is more enjoyable

  24. 2 years ago
    Anonymous

    if you want job opportunities, just learn react and do the common practices even though they're all stupid. Atleast you have a job and you know a widely used framework.

    React is my least favourite thing about javascript but it gets the job done and is used by most meaning i get jobs so unfortunately... I use react.

    If you want to make your own thing or if your job gives you options, then use something else 100%.

  25. 2 years ago
    Anonymous

    nodejs + express + ejs
    all you need

    • 2 years ago
      Anonymous

      I already do that but there is no job offer for ejs

      • 2 years ago
        Anonymous

        >jobs
        kys

        • 2 years ago
          Anonymous

          Life is good at mama's house incel?

          • 2 years ago
            Anonymous

            cope worktard

Your email address will not be published. Required fields are marked *