[HN Gopher] How to start a React Project in 2023
___________________________________________________________________
How to start a React Project in 2023
Author : antidnan
Score : 92 points
Date : 2023-03-23 19:57 UTC (3 hours ago)
(HTM) web link (www.robinwieruch.de)
(TXT) w3m dump (www.robinwieruch.de)
| wouldbecouldbe wrote:
| If you enjoy productivity on all levels (also performance) just
| go with Next. If you are a purist go vanilla js.
| bmikaili wrote:
| If you genuinely care about productivity go with Svelte. React
| is unproductive and unintutive.
| bottlepalm wrote:
| 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 wrote:
| You might be interested in this if you weren't already
| aware of it https://blitzjs.com/
|
| I've been using their superjson library with Remix & its
| pretty much solved all of my client/server type issues.
| jrsj wrote:
| Remix is worth checking out as well. I've had a great
| experience with it so far.
| stickfigure wrote:
| Create-react-app is deprecated? And the recommended replacement
| for SPAs is from the guy that makes Vue? What on earth?
| ppseafield wrote:
| 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 wrote:
| Yep, see
| https://github.com/reactjs/react.dev/pull/5487#issuecomment-...
| aobdev wrote:
| 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!)
| hoofhearted wrote:
| 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
| ggregoire wrote:
| I'd add to the article that Vite allows to make React components
| libraries too. Same tool to build your apps and your libraries.
| blowski wrote:
| > 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 wrote:
| 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.
| jcoletti wrote:
| npx create-next-app@latest myapp
| joemi wrote:
| 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?
| ldoughty wrote:
| I completely agree with this..
|
| I have been trying to get into front end JS development and it
| feels like every guide is broken within 6 months... When I
| actually succeed at one part, I then realize that to add
| testing, or bundling, I need to follow this other guide, which
| isn't stable anymore, and then breaks the whole project. I have
| tried 4 or 5 times now trying different frameworks and "quick
| start" features or following recent YouTube videos, giving it
| 3-5 hours each time, and I can't get a working typescript based
| UI + test + bundler to work.
|
| Edit: I should say, I'm open to any _working_ guides that go
| from start to bundle that you all know about...
| pcthrowaway wrote:
| > As someone who just decided to learn React (and modern
| javascript, after 1.5 decades or so of not programming in
| javascript at all
|
| Sorry you're experiencing this. It's not "just React" though,
| it's pretty much all Javascript (or Typescript) now. Especially
| front-end, but I swear, JS/TS on the front or back is like
| trying to learn to drive a car in heavy traffic while also
| repairing the brake lines which are malfunctioning
| keyle wrote:
| Saying it's not "just React" is normalising the problem,
| which I think really doesn't benefit React trying to set
| itself as the de-facto standard for front-end code.
| robear wrote:
| I write React but don't look at the docs much so I am not
| familiar with all the changes there. The basic concepts of
| React haven't changed much over its history. Hooks are newer
| than class components, etc but class components still work.
| Hooks have been out since 2019 so they aren't exactly new (and
| they were in the old documentation). React itself has been
| quite backwards compatible.
|
| The Javascript ecosystem tends to have lots of flux with new
| libraries and ways of doing things coming out all the time. I
| have found React to be one of the most stable libraries around.
| I can update versions of React and my code continues to work as
| before. Libraries that I depend on tend to have more issues
| with this and version updates can mean changes in the API for
| the library or a newer version of React not being supported.
|
| My suggestion for someone learning React would be to start with
| the simplest way of getting started and learn React before
| learning concepts brought in with frameworks, etc. If I were to
| start learning React today, I would start with Vite.
| _hao wrote:
| For context I'm a specialized back-end (but with a lot of
| experience in desktop GUI/game engine stuff) dev and I also
| wanted to learn React recently to round off my skills and be
| more marketable in the job market.
|
| Like yourself I also prefer written docs, but trying to find
| such structured info was an exercise in futility. At the end I
| used my existing Pluralsight subscription and went through the
| React 18 path they have which is around 18 hours or so in
| total. The courses covered different topics around React like
| components, hooks, testing etc. Good thing is the courses also
| have full transcripts! I followed them along and created some
| small apps myself in the process. Now I'm pretty much sure I
| can handle working with React in a normal job setting. You
| might want to consider that option. To be honest FE seems like
| programming on easy mode compared to some of the things I'm
| used to working on in my day to day. If you are an experienced
| programmer you should have no problem getting caught up to
| speed on that relatively quickly.
| firecall wrote:
| I've had a similar time reading the Firebase docs for Swift and
| SwiftUI!
| ggregoire wrote:
| > is it always such a chaotic changing climate around it?
|
| The old doc was like 10 years old, they just officialized the
| new one this week.
|
| Create React App was the recommended way to build a React app
| for like forever but Facebook stopped maintaining it 2 or 3
| years ago. The drop-in replacement is Vite.
| danlugo92 wrote:
| Start with The Tao of Redux
| schwartzworld wrote:
| 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.
| rzzzt wrote:
| 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
| nextaccountic wrote:
| It comes close, but it isn't mentioning Turbopack [0], the
| thing I'm using right now to replace webpack. Really happy with
| it so far. (Turborepo is a sister project, but I'm not sure how
| the two are related - if Turborepo depends on Turbopack or
| vice-versa - and in any case I don't need it)
|
| [0] https://turbo.build/pack
| nicoburns wrote:
| The article does a pretty good job of telling you which ones
| you need to care about and which ones you don't need to care
| about. And it's only 4-5 of these for a given project, which
| would look something like:
|
| - TypeScript (langauge) - React (framework) - Vite (build
| tooling) - ESLint (linter)
|
| That's not really any different to any other language. Maybe
| you have one extra tool in there for the build step.
| aaronrobinson wrote:
| What's your point?
| rzzzt wrote:
| It's ridiculous.
| [deleted]
| nwienert wrote:
| Can you name another industry in tech that doesn't have a
| lot of options? Lets try backend, database, infra, ML, data
| science.
| rzzzt wrote:
| 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.
| keyle wrote:
| I've stopped chasing front-end and fullstack roles and I know
| happily bang out PHP, because of this mess. PHP, think of the
| irony.
| 8note wrote:
| I think this would be more useful as a tree structure than as a
| list.
|
| Eg. Why would I need to care about electron and react native
| for a web app?
| rzzzt wrote:
| I dove into the article expecting some advice on "How to
| start a React Project in 2023", got a compendium of the JS/TS
| framework landscape instead.
| digdugdirk wrote:
| I'm a non-programmer, and recently I've been trying to turn a
| bunch of various time-saving scripts I've created over the
| years into a vaguely cohesive GUI. I figured aiming for a
| modern web gui framework (run locally) would be the way to go.
|
| This comment encapsulates the experience so, so well. I have no
| idea what is going on, everyone tends to have a _very_ strong
| opinion on which way to go, but no one can provide an
| explanation of the baby steps in how to get started. Or even
| why to get started. It 's maddening.
| headphoneswater wrote:
| [dead]
| agrippanux wrote:
| 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.
| yieldcrv wrote:
| 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
| aerzen wrote:
| A bit unrelated, but what happened to Angular?
| blowski wrote:
| 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.
| wetpaws wrote:
| Same thing that happens to every JS framework after a few
| years.
| candiddevmike wrote:
| 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.
| swsieber wrote:
| 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 wrote:
| 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?
| pictur wrote:
| 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.
| robopsychology wrote:
| Angular 14 is the latest version, last I looked it was 5.
| Things move so fast in FE world!
| iamsanteri wrote:
| 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.
| Bellend wrote:
| 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.
| jrsj wrote:
| 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.
| pictur wrote:
| Although I don't like some features of nextjs, it works for me.
| (things like server side prop management)
| leerob wrote:
| (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
|
| [2]: https://beta.nextjs.org/docs/configuring/static-export
| earthnail wrote:
| 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.
| gregors wrote:
| I'd definitely choose Rails or Phoenix over Astro.
| j-krieger wrote:
| Because Rails is awful. You do not need to choose JavaScript.
| Just don't go with Rails.
| WJW wrote:
| Which parts of Rails do you dislike? It can be terrible if
| done poorly but overall Rails is pretty good for fast
| iteration.
| hoofhearted wrote:
| We're using typescript to create static html like it's 1996
| again! Complete with inline styles and everything.
|
| In the web browsers eyes, a Next.js app is just a plain old
| html page load when you navigate within the app. I believe the
| days of SPA's and mounting on the bang# sign are dead. Some
| smart folks realized that it was more computational efficient
| to output plain old html like back in the days.
| deepsun wrote:
| 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.
| iamsanteri wrote:
| 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 wrote:
| 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 wrote:
| 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.
| EduardoBautista wrote:
| TypeScript.
|
| Rails is faster for building an MVP. But it's significantly
| worse than a project built with a typed language when it comes
| to extending and maintaining.
|
| I thought I had misconfigured Sentry (for error logging)
| because the type of errors that plague Rails, or any language
| that is not typed, just don't happen with a typed language
| (unknown method called on NilClass).
|
| We can decide to make a column in the DB to no longer allow
| NULL values, and we are immediately notified by the TypeScript
| compiler about every line that needs to be updated.
| ch4s3 wrote:
| > Rails is faster for building an MVP. But it's significantly
| worse than a project built with a typed language when it
| comes to extending and maintaining.
|
| I'm not sure that the academic work on software engineering
| really bares this out. Th Static vs. Dynamic debate is far
| from settled and increasingly looks to me like a matter of
| preference.
| chatmasta wrote:
| 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/t...
|
| [1] https://vitejs.dev/guide/#trying-vite-online
| twodave wrote:
| 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.
| nwienert wrote:
| 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
|
| Happy hacking!
| drinchev wrote:
| > 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.
___________________________________________________________________
(page generated 2023-03-23 23:00 UTC)