35 ms·

How to start a React Project in 2023

• blowski 4y ago
  > However, since SSR is becoming a more important topic these days Is it? This is the first I’ve heard of this fantastic news. What’s changed to have caused the increased importance?
  • chrisfosterelli 4y ago
    IMO the community shifted from SSR to SPA initially very rapidly due to the huge benefits over entirely SSR apps, but it came with some notable pain points and some new frameworks that incorporate parts of SSR have been attracting a lot of attention for solving those pain points. A lot of leading maintainers now feel that the best solution is more of a middle ground where frameworks support both server side and client side rendering with the developers given the flexibility to choose what renders where (or on both) depending on the app's needs. React is driving a lot of this now with server side components, but there's a lot of frameworks that were doing it beforehand which has inspired much of what they're doing now.
• agrippanux 4y ago
  I just built a ChatGPT-powered Spanish tutor for my son using Fresh from Deno and it was overall an enjoyable experience. Once I grok’d how islands worked it was pretty smooth sailing. I do love NextJS but I will try a few more Fresh projects soon.
• aerzen 4y ago
  A bit unrelated, but what happened to Angular?
  • wetpaws 4y ago
    Same thing that happens to every JS framework after a few years.
    • candiddevmike 4y ago
      Not sure what your definition of few is, but there are plenty of old, boring, stable frameworks out there that run perfectly fine, like Mithril. You don't have to constantly rewrite your frontend if you stick as close to raw JS/TS as possible.
  • pictur 4y ago
    Probably few people use it, but it is probably very useful for those who use it. I like angular's philosophy of trying to solve every issue in itself.
    • JenrHywy 4y ago
      Maybe it's not so popular for startups, but Angular is kinda like .NET - maybe not the new hot thing, but very well bedded down in large orgs and govt.
  • robopsychology 4y ago
    Angular 14 is the latest version, last I looked it was 5. Things move so fast in FE world!
    • iamsanteri 4y ago
      And soon quite a bit of us FE devs or any devs for that matter are nailed out anyhow, just look at the LLMs developing. Give it some time, haha.
    • operatingthetan 4y ago
      They started doing fast top level versions like Chrome, since Angular is Google too.
  • blowski 4y ago
    I learned Angular with v1. When v2 came out, it was so different I had to learn a new framework either way. I went with React because it was the one gaining the most traction. I think that’s what happened writ large.
  • swsieber 4y ago
    Angular doesn't play well with newer build tools - esbuild, vite, etc., making Angular quite isolated from the other frameworks. So a plug for vite is a plug for most frameworks except Angular (and others not on the radar). But also Angular has egregiously big build times as your project scales up, and that sucks.
    • Bellend 4y ago
      What about your developers though? Our company pays for 5 days a week 8 hours a day of talented humans in a medium team. I can throw compute for 1/10000th that. A 56 module Angular 15 codebase `npm start` takes 10 seconds, and compiles after change faster than a browser refresh. The build takes 67 seconds. What scale up are you talking about so that I know in the future what to look out for?
      • swsieber 4y ago
        I think we were at around ~150k lines of typescript I think. We were also stuck on Angular 12 due to browser compatibility issues (cries in IE11). I think we were looking at ~20s for the dev server and ~25 minutes for the the prod builds.
        • phist_mcgee 4y ago
          25 minutes?? Do you know which parts of the build are taking the longest? Transpiling, bundling etc?
          • Bellend 4y ago
            I'm struggling with those numbers personally.
  • Bellend 4y ago
    I still love it, after 6 years I don't really know what problem it isn't solving and I mean 10 versions later! Also keep it to yourself but RXJS, my old hatred is now responsible for some of the best code I have ever written as far as being proud is concerned.
    • jeremycarter 4y ago
      Couldn't agree more!
  • jrsj 4y ago
    Angular is basically headed down the same path that Ember went down IMO. A stable & mature but declining framework. The same could ultimately happen to React as well. I'm working on a new project right now using Remix, which is great, but I've also realized that really nothing I've done wouldn't have worked just as well without React. Fortunately I really enjoy Remix, but if SvelteKit or SolidStart provide a similar experience I don't really see why I would stick with React.
    • epolanski 4y ago
      Stable? dont they release breaking majors each 6 months?
      • jrsj 4y ago
        Technically yes but just because they have a scheduled major release every 6 months doesn’t mean you’re going to see significant breaking changes. They’re not as conservative as Ember in that regard (still on 3.x!) but relative to React, Vue, etc things aren’t changing as quickly.
        • epolanski 4y ago
          That's never been my experience at all. React's backwards compatibility has been always in a class of its own. Angular? Migrating from one major to another was always source of great pain.
  • valcron1000 4y ago
    Still the best choice in my opinion. Batteries included for pretty much anything and RxJS is a delight. I really never have to think about state management issues. My only concern are signals. They seem like worse Observables just for the sake of something new. Hope they never get added
    • doodlesdev 4y ago
      Just keep in mind that SSR in Angular is a bit more painful than in other libraries. It's also quite bloated in both development and production. Other than that I quite like it. RxJS takes some time to learn but pays off well. If you're ok with learning something with less adoption but similar batteries-included feel I'd recommend learning SvelteKit. I see it do a lot of things that Angular does well without failing were it's bad (i.e. breaking changes every six months).
  • SomeCollegeBro 4y ago
    I use Angular daily as a frontend for our C++ app, hosted in Electron. I personally love the fact that it's opinionated (using their router, DI, etc) and most of their API is pretty extensible. For our purposes, it beats out Qt if you want an app with a highly custom UI. We chose it over React for the simple fact that it is so "batteries included".
  • jamesfinlayson 4y ago
    I'm still using it - it does the job. I think there can be a bit more complexity than React (components, services, interceptors etc) but I've never found it to be hard to understand, even with all the extra stuff.
  • ioseph 4y ago
    Still heavily used in gov / enterpries / finance. Anecdotally after 6 years of React, switching back to Angular it has a huge learning curve. Such a large surface area with zonejs, rxjs, modules. I feel productive with it now and actually prefer services + rxjs to redux. I like how much is included and has established pattern but it feels very heavy handed, just adding a single component involves a stupid amount of boilerplat.
    • hdhrufjdi 4y ago
      Angular has a deprecated modules now, so dealing with components should be less work as well.
  • rk06 4y ago
    It is stuck on webpack, while everyone else moved to next gen tool. If you are new to angular, then I suggest stay away and come back in a year or two because Angular is going through a major paradigm shift. From webpack to esbuild, from zones to signals, from Rxjs everywhere to signals for synchronous change detection etc.
• pictur 4y ago
  Although I don't like some features of nextjs, it works for me. (things like server side prop management)
• earthnail 4y ago
  So we’re back to the old pre SPA web and even have a term for it: MPA If I build an MPA, why should I choose Astro if I can choose Rails? That’s a serious question to the HN community, not a rhetorical one - would very much love to learn if there’s something new here.
  • iamsanteri 4y ago
    After watching all this for a while, in order to get MVPs up and running while holding the IP and other things under control I’ve worked through RoR docs and did some projects in Django and I’d like to know more too. I’d bet on a re-emergence of traditional monoliths quite soon. That is if pocketbases and supabases aren’t going to be the new default which I’m not sure about right now. Recently built a site in NextJS and Nuxt though and I got to say it wasn’t that bad at all. But there’s something people are not considering enough and that is bringing value fast. That’s why I’m going deeper into Django (stability, reliability, value).
    • SCUSKU 4y ago
      The other thing that keeps me in the Django ecosystem is frankly Django Admin. If any of the JS backend frameworks would provide these out of the box things that basically everyone needs, I would be much more open to using them. For example, an admin panel for changing your models (like Django Admin), performance monitoring like Phoenix's LiveDashboard.
  • withinboredom 4y ago
    And you can use something like htmx to do everything on the server and use jquery to do fancy things. It’s a thing, especially for small one-off projects.
  • gregors 4y ago
    I'd definitely choose Rails or Phoenix over Astro.
  • deepsun 4y ago
    As I see it, basically the inertia that JS devs don't want to switch from their beloved horrors of NPM. Rails, Django/Flask or even Apache Struts or Java Spring would do good in this use case.
• chatmasta 4y ago
  If you're interested, this is the "absolute minimum" React project I was able to create, using esbuild (see `dev.mjs`) and some .html files. [0] It's a sub-package in a larger workspace, so there is some complexity inherited from the monorepo in terms of `tsconfig.json` and dependency management, but you can ignore that; the esbuild part was pleasantly simple to implement, and it pretty much "just works," such that each file in `www` is an entrypoint with one corresponding script from `pages/` that calls `createRoot(container).render(<App />)`. Note that's also a "sandbox" for development purposes. If I were creating a new production app today, I would probably use Vite, which uses esbuild under the hood anyway. It's super easy to get started [1] with not only React, but also Lit or Vue or any other number of pre-configured templates, and it takes care of all the drudgery of bundling and tests for you so that you can get straight to work. [0] https://github.com/splitgraph/madatdata/tree/main/packages/tiny-react-sandbox https://github.com/splitgraph/madatdata/tree/main/packages/t... [1] https://vitejs.dev/guide/#trying-vite-online https://vitejs.dev/guide/#trying-vite-online
• wouldbecouldbe 4y ago
  If you enjoy productivity on all levels (also performance) just go with Next. If you are a purist go vanilla js.
  • bmikaili 4y ago
    If you genuinely care about productivity go with Svelte. React is unproductive and unintutive.
    • bottlepalm 4y ago
      Tried it, went well for awhile, but when you get stuck it's tough to find support. Very small community. Probably 1000x less content/resources/references out there for it. On the other hand NextJS/React have been both productive and intuitive. There are so many examples out there and people are constantly talking about the nuances of both here and on other sites. It'd be great to see Next integrate something like TRPC/OpenAPI into it so calls to the backend could be statically typed. That would really polish up the end to end experience.
      • jrsj 4y ago
        You might be interested in this if you weren't already aware of it https://blitzjs.com/ https://blitzjs.com/ I've been using their superjson library with Remix & its pretty much solved all of my client/server type issues.
      • nailer 4y ago
        React was the same in 2014, Give Svelte time.
        • sapling-ginger 4y ago
          Svelte was released in 2016, it's 7 years old now. Year-to-year, it should match 2020 React.
          • 4y ago
• stickfigure 4y ago
  Create-react-app is deprecated? And the recommended replacement for SPAs is from the guy that makes Vue? What on earth?
  • ppseafield 4y ago
    It started out as one of his projects - an experiment to see if esbuild and native JS modules support in browsers could be used for development instead of webpack. It's become it's own project and has a large plugin ecosystem. The project doesn't involve vue, although it's the currently prescribed way to build vue projects now.
  • pcthrowaway 4y ago
    Yep, see https://github.com/reactjs/react.dev/pull/5487#issuecomment-1409720741 https://github.com/reactjs/react.dev/pull/5487#issuecomment-...
  • aobdev 4y ago
    It seems crazy, but it’s true. Also consider that Vite is a wrapper around 2 tools that are impressive in their own right: esbuild and rollup (and the latter was created by the guy who made svelte!)
  • WorldMaker 4y ago
    Vite is just an opinionated replacement for webpack, one of the biggest parts of create-react-app (which is obvious if you eject). This article's writer believes the out-of-the-box config for Vite is close enough to pre-eject CRA webpack config to be a drop in replacement. You could stick with webpack. Its defaults have gotten better, even if CRA never quite aligned with that shift. (It is still slow and prone to config-related crankiness, but you don't need two thirds of what CRA ejected.) So far in my own development, I find I generally prefer to use esbuild directly rather than the added weight of Vite and sometimes Vite feels like Create-React-App in that way that it obscures the power of the underlying components, though unlike Create-React-App Vite doesn't offer any sort of "eject" option. Vite adds some nice things like HMR support, but also now that browsers support script type="module" you can get nice dev experiences from unbundled modules without HMR and tools like esbuild/webpack become more of a "final pass" for Production rather than an always present development need. (Which is how Vite powers things like HMR, too, but you can do it by hand so easily now, I haven't yet been convinced to use Vite in a project.)
• joemi 4y ago
  As someone who just decided to learn React (and modern javascript, after 1.5 decades or so of not programming in javascript at all) in the past month or two, I've been extremely frustrated by the documentation (in particular) and the whole state of flux that it's in (in general). When I started with React, all the tutorials/guides on the site said "this is the old documentation, it's about to be replaced" on every single page. Still I worked through it and learned a bit. But by the end of working through it I figured "well, I might as well click the link that's on every page and see what modern React is like". So I tried to follow one of their guides and had issues with the very beginning. But I knew enough React to know what to do to fix the issue, so I did, and proceeded with the new guide, only to hit more problems immediately after that. So I gave up, and just stuck with the "old" way to do React. But then just 1 week after all those issues, the new docs were switched over to be the main docs. I'm honestly kind of afraid to try to work through them again and see if they fixed them already. And now I just read this article, and, well, I'm even less motivated to get into this stuff. Is this just a really bad time for React? Or is it always such a chaotic changing climate around it?
  • firecall 4y ago
    I've had a similar time reading the Firebase docs for Swift and SwiftUI!
  • schwartzworld 4y ago
    It might seem chaotic to you, but the docs change has been a long time coming, and isn't a surprise to anybody. > Is this just a really bad time for React There are some concepts you may struggle with. That's to be expected. But the new docs don't represent negative change. The old docs were not representative of how most react is written today. That was really confusing for newcomers. There's nothing "wrong" with doing it the old way, but most jobs that use React are going to require you to work with hooks in some capacity.
    • KyeRussell 4y ago
      How deep in the React ecosystem do you have to be to NOT see that the problems OP is describing are not inherent in change, but rather Meta deprioritising public / open-source React? You wouldn’t see this shit otherwise. Especially with Meta’s resources, there were MUCH better ways to handle React’s documentation situation. The JS community, but especially React, just happens to set the bar on the floor as far as end user communication goes, compared to other open-source projects, say…Django, with like…two paid staff and a bunch of volunteers. This isn’t just the cost of progress. It’s laziness.
• rzzzt 4y ago
  An incomplete sampling of the projects/frameworks/libraries mentioned in the article: - create-react-app - React - Vite - Webpack - esbuild - TypeScript - ESLint - Vue - Remix - Next.js - OpenNext - Astro - Gatsby - Parcel - Turborepo - React Native - Expo - Tauri - Electron - SvelteKit
  • aaronrobinson 4y ago
    What‘s your point?
    • rzzzt 4y ago
      It's ridiculous.
      • nwienert 4y ago
        Can you name another industry in tech that doesn't have a lot of options? Lets try backend, database, infra, ML, data science.
        • rzzzt 4y ago
          I feel there is a difference between all the domains you mention and frontend in that once you have made your choice regarding a single vendor or technology, very few vastly different avenues are left for starting a project. One example: 1) "How to start a Java project" - very vague, the article will arrive at your doorstep in book form as there are tons of possible ways depending on the use case 2) "How to start a REST API backend in Java" - a handful of bigger contenders are left on the table; some feature and performance comparisons could be handy 3) "How to start a REST API backend using Spring Boot" - a focused set of steps that leaves you with a controller class that will happily greet the user when a GET request is sent towards its general direction. I don't really want to explore the possibility of creating an application using NetBeans Platform or whatever at this point. Here the casual reader might think that we are at level 3, but it seems that it's closer to level 1.
• ggregoire 4y ago
  I'd add to the article that Vite allows to make React components libraries too. Same tool to build your apps and your libraries.
• twodave 4y ago
  I was fully expecting to see a one-liner for this article: npx create next app. I think this article overstates the disadvantages of using a framework like NextJS. If you don’t want to work on the bleeding edge, then don’t upgrade right away. That’s true of literally every library out there. And IMO it’s trivial to host a next app just about anywhere. Vercel has done a much better job with portability than you would typically expect from similar companies. The docs for NextJS are also just… rock solid. It really feels like they cover everything. I’m not affiliated, just a happy developer using their framework.
  • willdr 4y ago
    Vendor lock-in.
    • twodave 4y ago
      It is literally MIT licensed software. It’s no more vendor lock-in than React is in the first place.
      • johnny22 4y ago
        the license wouldn't be that important if say it was just covering over a vercel specific API. that's not the case here, but the license would be irrelevant if it's just talking to a vendor locked service.
    • 5Qn8mNbc2FNCiVV 4y ago
      Theres no vendor lock-in if you can scp your codebase to any vps and run `next build && next start` and have it work out of the box
  • leerob 4y ago
    Thank you, glad to hear the docs worked well! Let me know if you have any feedback.
• nwienert 4y ago
  If you are targeting native and web, I think the Tamagui + Solito starter that lets you share code between Expo/Nextjs is unbeat (disclaimer, I made Tamagui): Just `npm create tamagui@latest` See: https://tamagui.dev https://tamagui.dev Happy hacking!
  • ihateolives 4y ago
    Related: I really hate the trend of always using @latest. It's like in frontend there's no stable versions with known feature list and known bugs, it's always latest of whatever it is. Why?
    • nwienert 4y ago
      Latest ensures if you used it before it won’t use the old version. npm create otherwise will always use the starter script that you last used, which isn’t what you want in this case. You always want the latest if you’re starting a new project. For the first time you can leave it off, but it’s safer just to recommend always using it to avoid confusing stale create script problems down the road.
• drinchev 4y ago
  > bleeding edge tech solves many problems ... > which day to day tech workers working on internal B2B do not face That's so true. Good luck explaining to management that the front-end app needs additional cloud resources, such as a server, so we are on the edge of the trend with SSR. Most apps behind a login face tough architectural / security meetings, defending SSR for their use-case.
• hoofhearted 4y ago
  I’m currently working on a free open source framework for React developers and I’d love some feedback! It’s a batteries included React framework for scaffolding out a Stripe level frontend, complete with a blog and documentation. It’s built on top of Next.js, and is essentially free to host. :) Please check out my minimum viable prototype and tell me what you think: https://elegantframework.com https://elegantframework.com
• jcoletti 4y ago
  npx create-next-app@latest myapp
• yieldcrv 4y ago
  I love Next.js and don't find Vercel vendor lock-in from it. I've deployed a next app on github pages and it understood my folder based API structure fine
• leerob 4y ago
  (I'm on the Next.js team) Something we haven't done a great job of, so far, is talking about how you can use Next.js for SPAs or client-only React sites. You can start with basic HTML/CSS/JS, deploy and host anywhere, and then optionally opt-into features that require using a server (and host somewhere like a Node.js server or through a Docker container). Next.js can generate an HTML file per route, rather than having one large SPA bundle. There's been a lot of feedback around CRA no longer being recommended and folks looking for a replacement[1]—and uncertainty if Next.js is the correct solution. We've been working on some better docs[2] that help explain how to use Next.js without a server. [1]: https://twitter.com/dan_abramov/status/1636886736784457734 https://twitter.com/dan_abramov/status/1636886736784457734 [2]: https://beta.nextjs.org/docs/configuring/static-export https://beta.nextjs.org/docs/configuring/static-export
  • re-thc 4y ago
    It's not the same as traditional SPA, especially with that 1 file per route setting. This is SSG and does impact how and where it can be deployed. E.g. a traditional SPA (client only) can handle dynamic routes without extra intervention of a higher level router. Otherwise yes SSG can be useful :)
    • Secretmapper 4y ago
      I think you bring up a great point! But while true, nothing really prevents one from adding their own router that handles for them that's decoupled from Next.JS and it would largely function as a traditional SPA (in that the export/'SSG' only builds one page, a la a true SPA). And that IMO is kind of where the problem is - what level of abstraction should be added? Lots of beginners had problems because they were bombarded with the many confusing things to install to make something, and more often than not routing was one of them. It's just that Next.JS' is opinionated, but I'd argue so is everything else.
    • leerob 4y ago
      You can still do client-only routing (it was mentioned in the tweet linked above). It can be deployed anywhere that takes HTML/CSS/JS files.
• ilrwbwrkhv 4y ago
  How to start a React project in 2023: Don't. Seriously there is zero reason to use monstrous, painful software unless you're a sadist. Use something like solid or better yet go for a substantially better language like Imba, especially if you're a startup.
  • gardenhedge 4y ago
    Imba looks absolutely awful. I guarantee that will never take off!
  • tehbeard 4y ago
    I should maybe give solid a fair shake again, I don't think I got "Reactivity" or the signals stuff properly explained to me and got frustrated that something I could easily, competently do with react+setState just fell over or bugged out in their little demo / codepen (huge props to having that demo/codepen though, much nicer UX for a dev trying to learn than just documentation) But that Imba thing? I rewrote this and the kindest I can say is.... I don't see the value add? Learning it isn't going to be transferable?
    • slmjkdbtl 4y ago
      Reactivity is magnitudes simpler and more performant than react style state diffing, it's also much harder to write bad performance code because there's no react style re-rendering. The basic form of signal can be just function signal(value) { const subs = [] return { get: () => value, set: (newValue) => { value = newValue subs.forEach(f => f(value)) }, sub: (action) => subs.push(action), } } For building UI, when the component constructor sees a signal object being passed either to a property / children they'll automatically subscribe to the updates of this signal, and update the HTML property / children when there's an update to the signaled value. With this there's almost no overhead beyond setting those stuff yourself with vanilla JS (except for list updates, those still require diffing). Of course Solid's signal implementation is much more robust and have some very mild magic to make the UX better, but the core concept is really simple. Read about Solid's implementation here https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p https://dev.to/ryansolid/building-a-reactive-library-from-sc...
• taeric 4y ago
  Oh wow, this couldn't be more topical for me if it had to be. I seeded and maintained a react site at old job; so thought that I would do the same at new job. I'm more than a little wary, as I have seen how easily out of hand the front end can get. Any "services" we are writing will be backend and mirroring all of that effort on the frontend feels very misguided. Not at all happy that the first thing I stumble into is looking to be a giant featured framework.
• mrbonner 4y ago
  At this time in my life, learning to do front end work at work seems to be more difficult than reading and understanding the LLM paper from OpenAI (or Stephen Wolframe: How LLM works lengthy article). I did some front end work in the first 3 years of my career in server side render with JSP. We added jquery and the likes and it felt little complicated but manageable. Then I become mostly backend eng for the next 14 years. Now I feel like the dumbest folk in the group when it comes to talking UI framework. I know how those stuff works but the process to put them all together is akin to pulling teeth. And then there is a recent discussion at work about going back to SSR with hydration and get rid of react altogether. Hydration, SSR, improving response time by lower round trip calls, geez we did that in the early 2000s. Somehow I can’t help but thinking the way of shit we are in now maybe because of the ZIRP which is ending now. Maybe I can take a deep breath and say “things will be back to normal for fuck sake” Sorry for the rant :-)
  • javajosh 4y ago
    Things aren't normal because JavaScript in the browser is, technically, a very strange starting point for a computer revolution. It is quite different than the Unix REPL approach that preceded it. Much of the craziness is around shoe-horning javascript into the gcc paradigm (webpack) or shoe-horning gcc into javascript (webasm). The question I'd like to explore, is what if you just author web pages in html, css, and javascript? I feel like web standards are very good, browsers are incredibly powerful, to the point it may be safe to attempt this approach. Writing pages for modern browsers, with no polyfills, no transpilers, is quite pleasant. Writing JavaScript with arrow functions and destructuring and jquery-esque selector methods, and consistent event apis, is very pleasant. The module system is fine (I'm warming up to it). But how many professional front-end or full-stack folks would even know?
    • harrisi 4y ago
      I've messed around a little with this because I like the idea of zero-dependency websites. I think the biggest issue I have is how web components work. I really hate that JavaScript is required. At least with SSR you can have nice, scoped components that don't need JavaScript. I know it's more and more niche but if my project doesn't need JavaScript for functionality and only uses it to enhance some experiences when available, I simply cannot use standard web components without using some other tool to deal with SSR, but at that point why bother with writing standard web components if some framework has some other nice additions?
• doodlesdev 4y ago
  If you need a framework: NextJS (no, don't suggest Remix, every single good feature about it has been copied by every library and their grandpas) If you only need a bundler: Vite If you want to be happy: Don't.
  • Aeolun 4y ago
    Remix is very nice if you want to do any of the things they designed it for, and absolutely impossible if you want to do something else.
    • deleted 4y ago
      [deleted]
• iainmerrick 4y ago
  The frontend web framework landscape is pretty complicated and fragmented, sure, but is it really any different from backend? Take a look at Amazon’s or Google’s enormous list of cloud products and tell me your eyes don’t glaze over. And that’s not even the full ecosystem, it’s just the products directly supported by one company!
  • ldoughty 4y ago
    I think the difference is that AWS doesn't have seven frameworks for the same thing.. there certainly different levels to their services, but they generally are abstracting away the lower end each time they make a new product in a category.. There isn't really two different EC2-like systems, or two different S3 products, there's a new "popular" JS UI framework every year, and if you're still using the older framework 4 years later, it likely needs a heavy rework to upgrade to the latest version. I "learned" SQS 6 years ago, now I just keep up with the minor feature releases.. same with S3, and Lambda. In the same time I've looked at 4 different UI frameworks that have no overlap but try to do the same and result. Their services exist and they work.. and generally a guide from 5-10 yeas ago is still valid today (though the UI might be different, but the content remains reasonably valid)..
• 5Qn8mNbc2FNCiVV 4y ago
  Just use Next.js? If you just use it by following the getting started and don't use their SSR features if you don't want them, it will Just Work™ I really don't understand why the outcry even exists. It's recommended for a reason and whining about how SPAs still exists misses that no one ever said that it doesn't. The only thing people are mad about is that Vite didn't make the list but that's understandable because I could never tell the new React developers we just hired to do this project by themselves with Vite. But with Next.js (or whatever else on the list) it was a matter of "File here, this URL, your React component here. Don't think about SSR I'll take care of it if we need it." And it just works. Even too good because they run into issues so rarely that I forget that they make so much progress and we're already on our 3rd project with it. And they literally started coding 5 months ago. And if you care about what's going on under the hood, guess what? You're one Bing chat away from finding Vite and a few commands to have it running locally. Want SSR now too? Guess again, you are already setup to do exactly that in a way more ergonomic way than the low level Vite plugin (which I like, but I would never be able to hand-off to other developers)
  • crooked-v 4y ago
    Also, Next works reasonably well as a static site generator, too.
• silverwind 4y ago
  The esbuild diagram is quite misleading because Vite does not only use esbuild, but also rollup and postcss. Webpack can be set up with esbuild and will be equally fast, while being more flexible to configure, especially regarding multiple CSS entry points, which to my knowledge is not possible with Vite.
• hankchinaski 4y ago
  i can feel i am not the only one sharing the frustration on this, has anyone seen any dead simple js library or approach to build simple web apps that does not include boilerplates, builders, generators and what not? something like jquery but on steorids?
  • runlaszlorun 4y ago
    I haven’t built anything with it yet, but htmx looks promising.
• Aeolun 4y ago
  Honestly, for every new project I now use tRPC + Next.js, and I expect this to finally be the stack that will last me the next 10 years.
• mikojan 4y ago
  Both React's and NextJS' marketing is straight-up obnoxious. Currently, React Router is the only React framework that is even offering a solution to data fetching, mutations and transitions in the CSR space. Very basic problems. NextJS is not at all a CSR framework. In that space it suffers all the problems your average CRA application has.
  • leerob 4y ago
    https://news.ycombinator.com/item?id=35282577 https://news.ycombinator.com/item?id=35282577
• toastercat 4y ago
  I tend to only use esbuild on solo projects. It's simple, compiles JSX and TS, and the documentation is mostly easy to understand. The API also makes it easy to just create a `build.js` script I can call. As a bonus, it also includes live reload and a server these days. Vite seems like the best batteries-included solution that is still relatively lightweight compared to going all in on a framework like Next. I feel like the React folks are in this unfortunate position where they have to cater to people differently than other JavaScript libraries do, because to a lot of people, "React" means more than just a JavaScript library. And to some, they've never written JavaScript without React or even without build tools for that matter. I personally prefer the less-is-more approach to learning JS or any JS library (start with an .html file and a <script> tag, work your way up) and even though that may be a healthier way of learning React, it might frustrate more new users who just wanna make a shiny app.
• leros 4y ago
  I know it's not popular, but I still use "npx create-react-app" and have built successful apps with it. I'm sure I'm missing something, but it doesn't seem essential for my use cases.
• phero_cnstrcts 4y ago
  The best way to start a react app is to use Svelte.
• thr717272 4y ago
  As someone who does actual software engineering (although I have done my share of software tree houses and garages as well): If you don't have solid experience already: Don't plan your projects with anything except plain React configured with TypeScript. Use "Create React Application" (cra) to set it up and stick with the standards. Everything else you can add later - if you need it - and in the mean time you have the chance to move faster without breaking things and make better decisions. If you already have solid experience: consider this anyway if it is just another web application. I personally at least have seen a lot of time wasted because people always deviate from the standards both in React, Angular and Maven. When time comes to add things we think we need, think about the tokens mentioned in https://boringtechnology.club https://boringtechnology.club
  • unmole 4y ago
    A comment above said CRA is unmaintained and there were unfixed vulnerabilities. Is that not the case?
    • throw_away1525 4y ago
      CRA is no longer recommended. Official recs are Next, Remix, and Gatsby. https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project
      • thr717272 4y ago
        Seems you are right. More context here: https://github.com/facebook/create-react-app/issues/13077 https://github.com/facebook/create-react-app/issues/13077
    • thr717272 4y ago
      Last I checked the "unfixed vulnerabilities" where regex Denial Of Service at build time, see https://github.com/facebook/create-react-app/issues/11174 https://github.com/facebook/create-react-app/issues/11174
• gloosx 4y ago
  To start developing a react project - all you need is a file bundler and a local dev server. Luckily webpack provides both and as a long-time web developer I strongly recommend just doing `npm init; npx webpack-cli init;`. To get react going you just do `npm install react react-router-dom`. I don't know why the author is suggesting rather "how to a start a React Project constrained by some kind of a framework". So, let's recap the real rad method to start a React Project in 2023: npx webpack-cli init Advantages: 1. You get what you want: a web bundler and a dev server 2. No premature bargains or decisions, all this base belongs to you. 3. Expand infinitely and meaningfully with modules you will want to utilize for covering your app's use-case, starting with react and react-dom npx webpack-cli init Disadvantages: 1. Have to learn about your problems and discover solutions 2. Have to scroll through solutions documentation and configure them manually 3. Have to own your technical decisions and structure
  • crubier 4y ago
    > 1. You get what you want: a web bundler and a dev server No I just want to build an app fast. Frameworks allows this to. One NPX command gets you a running app. > 2. No premature bargains or decisions, all this base belongs to you. Cool now you're the only snowflake in the world with a setup like your custom setup. All online help on frameworks people commonly use is useless to you, good luck > 3. Expand infinitely and meaningfully with modules you will want to utilize for covering your app's use-case, starting with react and react-dom Nope, with this naive approach you will soon encounter scalability problems, you will need code splitting, (per page maybe?), and you will inevitably re invent NextJS or a similar framework. > 1. Have to learn about your problems and discover solutions I want to focus on my client's problems not my problems > 2. Have to scroll through solutions documentation and configure them manually Yep > 3. Have to own your technical decisions and structure There is enough to own in this world. I guess you're also the kind of person who want to build your own Linux Distro and own the entire stack?
    • gloosx 4y ago
      My npx command gives you the runnable app too, the problem with your approach is just that it is superficial, and it doesn't show a lot of comprehensions. I don't have any problem with that, since that places you behind in the competition. I see why you would want to use Next.js in order not to build it yourself, but in the first place, I don't see why you need Next.js features for a plain React app at all, and what benefits it gives, I don't see why you need to be renting a whole VPS for hosting that. React projects are typically statically built single-page apps which are not required to be statically rendered or dynamically served, you can serve the static bundle itself on a file-hosting, so the title of an OP post is just misleading, it clearly says "How to choose a framework for your React Project in 2023"
• rco8786 4y ago
  Does anybody else think it's extremely damning that a mature framework such as React still has no agreed up on way to start a project? One of React's initial selling points was that it was a library, not a framework! React is unopinionated! Etc. Perhaps some opinion might have been better, in hindsight. How is `react new` not a thing?
  • Zealotux 4y ago
    It appears the layoffs affected the React team, and the once-standard way for starting a new framework-less project (CRA) isn't supported anymore. The ecosystem is confusing, but I'd argue it's still quite straightforward to start a new project: either use one of Vite's basic React templates or Next if you want an opinionated framework.
    • hnbad 4y ago
      I don't think it's fair to blame CRA's state of disrepair on the layoffs. CRA has been barely maintained for years now and what releases it did receive were mostly to update its dependencies. CRA was created out of a need for a "blessed" starter but it feels like the hope was that it would spark competition so it could be replaced with something else.
      • Zealotux 4y ago
        I agree! I meant to say the layoffs were probably the final nail in the coffin for CRA. Honestly, I always disliked CRA, and I'm glad to see it go.
        • mst 4y ago
          The existence of craco to deal with CRA being opinionated to a fault is both awesome (in that I <3 the craco devs for making it, especially given when I discovered it I was right on the verge of reinventing it in a fit of rage and they'd already done it better than I would have) and something of a demonstration that one can take opinionation too far such that it becomes evolutionarily maladaptive.
• Zetice 4y ago
  I started a new React project earlier this week and ran into approximately zero of the issues or concerns mentioned here in the comments. I genuinely don’t get why the webdev community insists in making their jobs so difficult by refusing to actually learn the tools they’re using. CRA is unnecessary, Next.js is unnecessary. The simple tutorial on the React website gives you everything you need to get started, and you can research which other tools you need once and be good forever.
• basicallybones 4y ago
  I recently showed the (old) React Hooks documentation to my 70-year-old mentor, a comp sci PhD who started on punch cards and never stopped. I wish I had taken a reaction video of the flabbergasted look on his face when he was reading the React docs section titled "Classes Confuse People and Machines" (https://legacy.reactjs.org/docs/hooks-intro.html#classes-confuse-both-people-and-machines https://legacy.reactjs.org/docs/hooks-intro.html#classes-con...). Now, I like React, more or less. But some of the discussion around React reminds me of Wimp Lo from Kung Pow ("...we trained him wrong as a joke..."). For instance, the whole immutability for performance thing (I get it, but lol). Or statements like this: "[w]ith Hooks, you can extract stateful logic from a component so it can be tested independently and reused" (thank God someone finally figured out how to reuse stateful logic in software /s).
  • dimal 4y ago
    Saying hooks are less confusing than classes and understanding the weirdness of `this` is a pretty bad selling point and easily refuted. Hooks are weird. Really weird. They make all your components that use them impure which makes them harder to reason about. But hooks do compose better than classes. With classes, everything is tied to `this` which means that if you decide to reuse some stateful or effectful(?) logic somewhere, you have to disentangle it from `this` first. So on the whole, I think hooks are a win over classes. But they are weird and confusing.
  • joshmanders 4y ago
    Yeah that's one of the biggest annoyances of the frontend community in general to me. This constant "We have to do X because Y confuses developers" uhhhhh maybe they should expand their knowledge instead of putting bumper rails on everything causing pain for everyone.
  • yamtaddle 4y ago
    I had to read the code when hooks came out, because I couldn't believe they'd done the thing that the documentation of hooks' behavior sure made it look like they'd done. Sure enough, they had. I was left in a state somewhere between dumbfounded and amused. Reading the justifications for what they'd done just made both reactions more intense.
• okeuro49 4y ago
  As someone new to React, but who has used Webpack, I'm glad that CRA is gone. It felt like "ravioli code" to me, and it seemed wrong that everyone was reluctant to use "eject", but then you couldn't configure any of the underlying tools, like Webpack, easily either. Tools should be easily composable, they shouldn't be clumped together with an inflexible "ravioli" abstraction.
  • steve_adams_86 4y ago
    The irony of CRA is that it would become a system you needed to learn in and of itself in order to navigate the treachery of trying to manage a modern React app. I’m not disparaging it generally though. It was truly useful to many people and reduced barriers to allowing people to more easily experience React. Arguably, the mess of needing to understand internals of CRA to solve weird bugs or needing to eject was in some ways a good thing. Perhaps people wouldn’t have made it that far without the initial ease of building with react! You’re absolutely right though. The design of CRA imposed a lot of inevitable issues. Partially due to how webpack works and due to (in my opinion) the fragility of the npm ecosystem. There was so much complexity and so many dependencies. Perhaps some of these things changed for the better over time — it has been a while since I looked at it. The last time I did, that aspect was labyrinthine and awful to navigate when things went wrong.
    • okeuro49 4y ago
      > I’m not disparaging it generally though. Definitely, it was neat how the developers gave you a survey if you did use "eject". But I think the answer is to deal with the issue of making tools more easily composable, or improving the documentation of how to use them, rather than providing the abstraction.
  • mst 4y ago
    I am not much of a fan of CRA myself but I am very much glad that https://craco.js.org https://craco.js.org exists - so far it's handled my needs for tweaking CRA behaviour in situations where "eject" didn't seem like a good route to take. Mostly tbh to stop the freaking thing spawning inotify watchers for the entire contents of node_modules - I don't mind having to do a manual restart when I've changed dependencies and I definitely -do- mind having it eat a shedload of my user's inotify kernel allocation. (I know you can up the allocation, that's not the point, why are you on my lawn? :)
• moomoo11 4y ago
  Use svelte. Trust me. JS/TS + html and css The biggest svelte complaint I see is that there aren’t enough libraries. That’s because it is trivial to built things with svelte. And as a UI engineer you should know how to build, not just npm install some-shit Source: former UI tech lead, been using react since Dec 2015 and have built apps with it that are used by millions of users.
  • Hexigonz 4y ago
    I dev in svelte/kit full time. I’ve built a ton of projects with it after doing corporate react stuff for a couple years. I’m so tired of hearing people say “well the ecosystem for react is stronger because of how many libraries there are.” No, that’s not a good sign for a framework. If you need an enormous ecosystem of helpers to get anything done, that’s a detriment. Svelte doesn’t have libraries because it doesn’t need them. Kit comes with tons of out of the box features, and there’s nothing I can’t achieve with either: 1. My own JavaScript code. 2. An NPM package IF need be. Seriously. Svelte has everything react has, with a much better developer experience. It’s the evolution of vanilla web, and even if I got canned tomorrow, I would search until I found another job with either stack freedom or svelte as it’s framework.
• grishka 4y ago
  How to start a react project: don't. Use raw browser APIs. Maybe build yourself some thin wrappers for those APIs that you find awkward to use as is. I genuinely don't understand why so many people want to abstract the platform away in projects that only run on a single platform (the browser in this case). You want to be as close to your platform as possible if you care about performance and resource use.
  • cyclotron3k 4y ago
    And once you've assembled your thin wrappers, and a few utility functions that really improve QoL, it would be a shame not to share it with the community. So make a cute name and logo, make a website using words like "superhero" and "fun!", and make an announcement on Hacker News (where someone will invariably make some comment about not needing a framework lol)... then toss it in the pile with the thousands of other (unmaintained) front end frameworks.
  • throw_away1525 4y ago
    I care about shipping products to customers for feedback, and then iterating as quickly as possible once I get it, so that I can earn as much money as possible. Have fun with your performance and resource use, though. Sounds really interesting.
• TAKEMYMONEY 4y ago
  > [Vite is] almost drop-in replacement for create-react-app (CRA) Can anyone with experience replacing CRA with Vite speak to how true this is?
• dSebastien 4y ago
  An interesting article, but it's unfortunately one more that misses the elephant in the room: Nrwl NX: https://nx.dev/ https://nx.dev/
• Alifatisk 4y ago
  Someone should map out every frontend framework and it's path to everything, from SPA to SSR & which libraries that exists within that ecosystem. Nvm, roadmap.sh/frontend came to my mind.