5 ms·

That's not _React_, that's `create-react-app`, which was built long ago, and isn't really used so much today for starting new projects (for obvious reasons). (I

That's not _React_, that's `create-react-app`, which was built long ago, and isn't really used so much today for starting new projects (for obvious reasons). (In fact, it's considered deprecated) Check out Vite: https://vitejs.dev/ https://vitejs.dev/ `npm create vite@latest` run through the process --> `added 217 packages`

jdthedisciple 3y ago
Not really on topic but I mean I would usually go with NextJS since it just works so well with Vercel, providing a really convincing, complete solution. But I will check out Vite nonetheless, curious how it fares against it...
- whatamidoingyo 3y ago
  > But I will check out Vite nonetheless, curious how it fares against it... It is 100x better. :)
  - jdthedisciple 3y ago
    Wait upon quick glance Vite doesn't come with SSR support ... ? Yea guess I'll stick with NextJS
    - ironmagma 3y ago
      SSR support is only needed for public-facing websites that will undergo some kind of search engine indexation. For most apps this is not necessary since most apps are not accessible publicly.
      - verdverm 3y ago
        NextJS does more than SSR, like determining routing based on directories and making React Server Components and Actions so simple it's hard to not choose NextJS They've removed a ton of pain from full stack React/JS/TS
        ironmagma 3y ago
        OK, but on the other hand I've heard from someone who worked at a startup that unnecessarily chose NextJS despite no requirement, and it really held back the organization for the rest of its existence, limiting velocity. Simple things like fetching queries become harder due to the split lifecycle. Relevant HN thread: https://news.ycombinator.com/item?id=36472166 https://news.ycombinator.com/item?id=36472166
        verdverm 3y ago
        Yeah, you definitely buy into a paradigm and ecosystem that has its own flaws. It's all tradeoffs and right for for sure. My new project requirements for well with NextJS. I was mainly pointing out that there are a number of benefits for the drawbacks.
        moon_moon 3y ago
        [dead]
    - romanhn 3y ago
      I built a React SSR app on Vite using Vike (https://vike.dev https://vike.dev), it worked well enough for my simple needs. Best part was I was able to easily reuse a bunch of components from the primary React SPA app that lives side-by-side in the same project without needing to buy into the "Next.js way".
  - solardev 3y ago
    IMO Vite isn't better or worse, it just has a different use case. Next has more bolts included (like robust SSR + fetching/caching strategies, routing, middleware, etc.) If you're just building a SPA, using Next is overkill (and will often get in the way, actually). But for some other websites, having all of that included and supported by a single source/vendor is very valuable and beats trying to Frankenstein a project out of 30 other libs like the bad old initial days of React. For simpler or client-only sites, Vite is actually wonderful. But it's not automatically the best choice for every project.
  - bezier-curve 3y ago
    It's best to compare it to Webpack - both are pretty good. Vite is intuitive with fast build times and has HMR that's easy to configure. Webpack takes effort to configure but will likely have a well supported plugin for any edge case.
firemelt 3y ago
this evan you guys always could simplify things that made complicated by front end folks
- reaperman 3y ago
  I'm sorry, I'm having trouble parsing this sentence. Could you rephrase it more clearly?
  - CharlieDigital 3y ago
    Evan You, creator of Vue and Vite. Really interesting guy. Good podcast here: https://corecursive.com/vue-with-evan-you/ https://corecursive.com/vue-with-evan-you/ and very, very much worth a listen. His background isn't even software engineering but he has come to spearhead (at least?) two very major projects that have shaped modern web development: Vue and Vite. Both Vue and Vite are notably "simple" and fast relative to their contemporaries. Vue really stands out as one of the few, pure community driven front-end frameworks that has achieved major uptake (both React and Angular came from the commercial space).
  - yieldcrv 3y ago
    This Evan You guy always could simplify things that were made complicated by frontend folks
- thiht 3y ago
  Completely unparseable sentence if you don’t know Evan You is a person. Capital letters are not just for cosmetics
jhardy54 3y ago
> (In fact, it’s considered deprecated) That’s not true. https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project Vite fans recommend Vite, but that doesn’t change the official documentation.
- codingdave 3y ago
  I'm not sure what you are seeing on that page that makes you think create-react-app is not deprecated. It isn't listed on that page at all - there are more modern choices listed.
huehehue 3y ago
The ecosystem sounds no less insane with this answer. I run into "<X> is deprecated, use <Y>" constantly at a dependency level, at a framework level, and at a paradigm level. Also, what's Vite? The React docs mention Next.js, Remix, or Gatsby. At what point would any of these become deprecated? To be clear, I'm just complaining, but you could change the OP's question to read as "How in the world can this number of <dependencies/frameworks/paradigms/languages> be considered sane and normal, and most of all, necessary?" and it would still make sense
- solardev 3y ago
  As a JS dev, the situation annoys me too, but I'll say at least it's a lot better than it used to be. We've gone from "manually clobbering together 30 different libraries to make an app" to "choosing one of 3-5 major frameworks". Yes, those frameworks themselves still have hundreds of sub-dependencies, but usually they're managed by the upstream framework maintainers and upgraded at once. Like you upgrade your Next/Remix/Vite version and then rest of it should take care of itself, with (usually) the framework vendor providing detailed changelogs and code migration tools if necessary. It's not a perfect system but it's a heck of a lot easier than it used to be. And once you build for production, those hundreds of libs just get tree-shaken and bundled into a few much smaller minified and compressed JS files, and often rehydrated only after the important HTML loads. Done right, it can be better UX than the old SPA days -- at a cost of increased slightly increased mental complexity for developers, but not much more than having to work full-stack in different languages. The ecosystem is very slowly maturing. IMHO we're probably post-peak now. The last 5-7 years had a huge explosion of JS frameworks because, well, that's the language of the web, and we saw a ton of startup activity. But now that the industry is moving towards AI instead, the web is no longer cool, and probably we'll see a lot less competition/innovation and more consolidation/stagnation. I doubt many of these frameworks will survive long term. My personal guess (only) is that we'll probably only be left with Next and Vite(*) after a few years, with the others fading into history the way Ember, Backbone, Angular, etc. did. > At what point would any of these become deprecated? Probably 2-4 years, if history is any indication. They just get less popular and less maintained over time, but there'll always be a long tail of older unmaintained projects running on life support with vulnerable versions, etc. But most projects will move on. In my career as a web dev, I've never seen production frontend code last more than a couple years without drastic changes anyway, so I doubt it really matters. Good excuse for the next generation to rewrite everything from scratch for the nth time, lol. Management's visions and priorities rarely last that long to begin with, so it all just kinda works out... shrug. I wouldn't build a time capsule in JS, but for websites that by their nature are ephemeral... sure, why not? -------- * Vite is just a simple frontend processor and bundler: https://vitejs.dev/guide/features.html https://vitejs.dev/guide/features.html It includes things like TypeScript, JSX, hot module replacement... etc., that used to be a bunch of separate libs. It's heavier than vanilla JS, but much lighter than Next.js. Great for simple SPAs, but if you need more batteries included, Next can get you (much) further before you start having to add in more third-party packages again. Think of these like a Venn diagram. Vite is a small circle that has a lot of overlap with Next's much bigger circle.

jdthedisciple 3y ago

Not really on topic but I mean I would usually go with NextJS since it just works so well with Vercel, providing a really convincing, complete solution. But I will check out Vite nonetheless, curious how it fares against it...

whatamidoingyo 3y ago
> But I will check out Vite nonetheless, curious how it fares against it... It is 100x better. :)
- jdthedisciple 3y ago
  Wait upon quick glance Vite doesn't come with SSR support ... ? Yea guess I'll stick with NextJS
  - ironmagma 3y ago
    SSR support is only needed for public-facing websites that will undergo some kind of search engine indexation. For most apps this is not necessary since most apps are not accessible publicly.
    - verdverm 3y ago
      NextJS does more than SSR, like determining routing based on directories and making React Server Components and Actions so simple it's hard to not choose NextJS They've removed a ton of pain from full stack React/JS/TS
      - ironmagma 3y ago
        OK, but on the other hand I've heard from someone who worked at a startup that unnecessarily chose NextJS despite no requirement, and it really held back the organization for the rest of its existence, limiting velocity. Simple things like fetching queries become harder due to the split lifecycle. Relevant HN thread: https://news.ycombinator.com/item?id=36472166 https://news.ycombinator.com/item?id=36472166
        verdverm 3y ago
        Yeah, you definitely buy into a paradigm and ecosystem that has its own flaws. It's all tradeoffs and right for for sure. My new project requirements for well with NextJS. I was mainly pointing out that there are a number of benefits for the drawbacks.
      - moon_moon 3y ago
        [dead]
  - romanhn 3y ago
    I built a React SSR app on Vite using Vike (https://vike.dev https://vike.dev), it worked well enough for my simple needs. Best part was I was able to easily reuse a bunch of components from the primary React SPA app that lives side-by-side in the same project without needing to buy into the "Next.js way".
- solardev 3y ago
  IMO Vite isn't better or worse, it just has a different use case. Next has more bolts included (like robust SSR + fetching/caching strategies, routing, middleware, etc.) If you're just building a SPA, using Next is overkill (and will often get in the way, actually). But for some other websites, having all of that included and supported by a single source/vendor is very valuable and beats trying to Frankenstein a project out of 30 other libs like the bad old initial days of React. For simpler or client-only sites, Vite is actually wonderful. But it's not automatically the best choice for every project.
- bezier-curve 3y ago
  It's best to compare it to Webpack - both are pretty good. Vite is intuitive with fast build times and has HMR that's easy to configure. Webpack takes effort to configure but will likely have a well supported plugin for any edge case.

firemelt 3y ago

this evan you guys always could simplify things that made complicated by front end folks

reaperman 3y ago
I'm sorry, I'm having trouble parsing this sentence. Could you rephrase it more clearly?
- CharlieDigital 3y ago
  Evan You, creator of Vue and Vite. Really interesting guy. Good podcast here: https://corecursive.com/vue-with-evan-you/ https://corecursive.com/vue-with-evan-you/ and very, very much worth a listen. His background isn't even software engineering but he has come to spearhead (at least?) two very major projects that have shaped modern web development: Vue and Vite. Both Vue and Vite are notably "simple" and fast relative to their contemporaries. Vue really stands out as one of the few, pure community driven front-end frameworks that has achieved major uptake (both React and Angular came from the commercial space).
- yieldcrv 3y ago
  This Evan You guy always could simplify things that were made complicated by frontend folks
thiht 3y ago
Completely unparseable sentence if you don’t know Evan You is a person. Capital letters are not just for cosmetics

jhardy54 3y ago

> (In fact, it’s considered deprecated) That’s not true. https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project Vite fans recommend Vite, but that doesn’t change the official documentation.

codingdave 3y ago
I'm not sure what you are seeing on that page that makes you think create-react-app is not deprecated. It isn't listed on that page at all - there are more modern choices listed.

huehehue 3y ago

The ecosystem sounds no less insane with this answer. I run into "<X> is deprecated, use <Y>" constantly at a dependency level, at a framework level, and at a paradigm level. Also, what's Vite? The React docs mention Next.js, Remix, or Gatsby. At what point would any of these become deprecated? To be clear, I'm just complaining, but you could change the OP's question to read as "How in the world can this number of <dependencies/frameworks/paradigms/languages> be considered sane and normal, and most of all, necessary?" and it would still make sense

solardev 3y ago
As a JS dev, the situation annoys me too, but I'll say at least it's a lot better than it used to be. We've gone from "manually clobbering together 30 different libraries to make an app" to "choosing one of 3-5 major frameworks". Yes, those frameworks themselves still have hundreds of sub-dependencies, but usually they're managed by the upstream framework maintainers and upgraded at once. Like you upgrade your Next/Remix/Vite version and then rest of it should take care of itself, with (usually) the framework vendor providing detailed changelogs and code migration tools if necessary. It's not a perfect system but it's a heck of a lot easier than it used to be. And once you build for production, those hundreds of libs just get tree-shaken and bundled into a few much smaller minified and compressed JS files, and often rehydrated only after the important HTML loads. Done right, it can be better UX than the old SPA days -- at a cost of increased slightly increased mental complexity for developers, but not much more than having to work full-stack in different languages. The ecosystem is very slowly maturing. IMHO we're probably post-peak now. The last 5-7 years had a huge explosion of JS frameworks because, well, that's the language of the web, and we saw a ton of startup activity. But now that the industry is moving towards AI instead, the web is no longer cool, and probably we'll see a lot less competition/innovation and more consolidation/stagnation. I doubt many of these frameworks will survive long term. My personal guess (only) is that we'll probably only be left with Next and Vite(*) after a few years, with the others fading into history the way Ember, Backbone, Angular, etc. did. > At what point would any of these become deprecated? Probably 2-4 years, if history is any indication. They just get less popular and less maintained over time, but there'll always be a long tail of older unmaintained projects running on life support with vulnerable versions, etc. But most projects will move on. In my career as a web dev, I've never seen production frontend code last more than a couple years without drastic changes anyway, so I doubt it really matters. Good excuse for the next generation to rewrite everything from scratch for the nth time, lol. Management's visions and priorities rarely last that long to begin with, so it all just kinda works out... shrug. I wouldn't build a time capsule in JS, but for websites that by their nature are ephemeral... sure, why not? -------- * Vite is just a simple frontend processor and bundler: https://vitejs.dev/guide/features.html https://vitejs.dev/guide/features.html It includes things like TypeScript, JSX, hot module replacement... etc., that used to be a bunch of separate libs. It's heavier than vanilla JS, but much lighter than Next.js. Great for simple SPAs, but if you need more batteries included, Next can get you (much) further before you start having to add in more third-party packages again. Think of these like a Venn diagram. Vite is a small circle that has a lot of overlap with Next's much bigger circle.