[HN Gopher] React is 10 years old
___________________________________________________________________
React is 10 years old
Author : ggregoire
Score : 144 points
Date : 2023-05-30 15:36 UTC (7 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| roschdal wrote:
| What will succeed React?
| yazaddaruvala wrote:
| To de-throne React, React would have to stop de-throning
| itself.
|
| I do think the future of DOM based diffing is no longer going
| to use a Virtual DOM. Svelte has shown the way. It just has to
| be moved into React (or a React successor).
|
| I also think the future of Components is to use async/await
| more. Where each await point is assigned a fallback component
| e.g. <Loading /> or something.
|
| React also needs to figure out Hooks a bit better, and see if
| there is a missing language feature that can be pushed to
| simplify that concept.
|
| If something (including React) is able to do those three
| things, while also keeping/improving the React DX (markup and
| logic together, uni-directional dataflow, hook like annotations
| that can interoperate with each other), it'll likely de-throne
| React.
| leerob wrote:
| Have you seen React Server Components? You mark a component
| as `async`, and then you `await` some Promise inside of the
| component to fetch data. The fallback points are
| declaratively defined through React Suspense. For example:
|
| <Suspense fallback={<LoadingSkeleton />}>
| <MyComponent />
|
| </Suspense>
|
| Where your Server Component then looks as follows:
|
| async function MyComponent() { const data =
| await db.get('...') return ...
|
| }
|
| https://nextjs.org/docs/getting-started/react-essentials
| yazaddaruvala wrote:
| Yes, aware. Its cool, but the ergonomics feel very much the
| way I felt about Node.js with callbacks.
|
| There is a different type of delight that comes from the
| ergonomics on async/await. This is the big jump React
| Suspense also needs to make. I am not smart enough to
| suggest anything here tho. I just know the framework
| (including React) that can give me that async/await delight
| while using Suspense will dominate!
| kristopolous wrote:
| Sanity hopefully
| phendrenad2 wrote:
| In my opinion? GTK on Wayland under WebGPU. You laugh now...
| ativzzz wrote:
| 2030 will be the year of the linux desktop
| hu3 wrote:
| Succeed implies that it reigns supreme. But Vue and Angular has
| been significant for a long time now.
|
| https://survey.stackoverflow.co/2022/#section-most-popular-t...
|
| My bet for next-gen frontend tech is on svelte and SolidJS.
| They are faster, lighter and their tooling scene isn't as
| fragmented.
| 8note wrote:
| Looks like jQuery might get a comeback before vue and angular
| do anything based on that graph
| hu3 wrote:
| Sure, if you consider 18% and 20% as doing nothing.
| elforce002 wrote:
| It'll be a long time before something comes along and dethrone
| react. React ecosystem is too vast and the community is large
| and engaged. Nothing comes closer to React atm.
|
| Other than that, prob. lit-dev (with time).
| azangru wrote:
| > Other than that, prob. lit-dev (with time).
|
| Yes. Nothing excites me more than web components and moving
| closer back to the browser. Somehow, it feels more exciting
| than server components, signals, compilers, resumability,
| etc. etc.
| FactualActuals wrote:
| I don't think React will be replaced for a very long time. The
| only library that has somewhat similar adoption rates to early
| React is Vue. I personally prefer Vue over React and I use it
| at work. But I would be happy using React as well if the choice
| was given to me. Vue3 + Composition API just makes sense to me.
| oblak wrote:
| Vue 3 + pinia is simply an amazing experience. Nothing is
| shoved down your throat
|
| I tried getting back to React but Vue makes so much more
| sense. Feels like in the old days because all you do is write
| your code instead of dealing with a library and its ways.
| [deleted]
| belter wrote:
| This whole discussion is concerning. So can somebody please point
| me to what is considered the modern React way? Educational
| resources, Tutorials, Docs please? Or is this modern way based on
| Beta documents?
|
| Edit: Is this the place to start? - https://react.dev/
|
| From what I see from the tutorials...Why the closeness to NodeJS?
| tracker1 wrote:
| That would be a good place to start. Node.js is the defacto
| standard for JS based tooling, along with npm (node package
| manager) as a public module repository. There has been some
| evolution in the space.
|
| If starting a project, I'd probably start with Parcel.js [1]
| and from there use typescript/tsx instead of JS as a core. But
| that's just me. I also tend to do Redux the "hard way" closer
| to the original structure instead of redux-toolkit, as I find
| it's more overhead to learn initially but avoids a lot of
| additional complexity over time.
|
| 1. https://parceljs.org/recipes/react/
| itsuka wrote:
| To celebrate React 10th anniversary, Next.js interviewed Andrew
| and Sebastian from React core team:
| https://www.youtube.com/watch?v=g5BGoLyGjY0
| epolanski wrote:
| Whatever one feels today about React, there is no doubt that it
| has given functional and declarative programming an important
| light.
|
| Not in the sense that React itself is functional or declarative
| (it isn't albeit its roots are in Ocaml), but the style of
| programming it introduced to many millions of web developers made
| a sizeable chunk of them interested in fp and many of those
| percolated to strictly typed FP in TS, Elm or Haskell.
|
| Pretty much every major fp language has tried to implement their
| own declarative UI after React's success, be it for terminal
| applications or native development.
| davedx wrote:
| Yup! I actually discovered react via Om, which lead my down a
| delightful mind bending journey into ClojureScript and lisps.
| Awesome
| noman-land wrote:
| I think these two are React's biggest lasting contributions.
| Describing UI in a declarative way, and introducing many
| functional programming concepts to the world's JS devs.
|
| I myself fell in love with functional programming in part
| because of many of the concepts I was introduced to by the
| likes of Dan Abramov and company.
|
| It led me down paths of research I wouldn't have known to go
| down, all the way back to the dawn of computer programming.
| zuprau wrote:
| > React's biggest lasting contributions. Describing UI in a
| declarative way
|
| I feel that AngularJS (v1) did that years before React, and
| maybe even other MVC frameworks before that.
|
| I can't think of anything React brought in that earlier
| frameworks didn't already have in a form or another. Maybe
| hooks? Arguably the worst and least performant part of React.
|
| It only popularized "HTML-in-JS" but that has always been
| possible via strings or file imports. Even template pre-
| compilation was part of Backbone or Ember (I don't remember
| which)
| brundolf wrote:
| > I feel that AngularJS (v1) did that years before React,
| and maybe even other MVC frameworks before that.
|
| Angular markup lives in _templates_ which are used to
| _generate and update_ the UI, while React markup lives in
| _expressions_ which evaluate to _values_. This is a subtle
| but key difference. I would argue React isn 't even an MVC
| framework (though it sorta pretended to be one for a while)
| baja_blast wrote:
| React popularized and brought one way data flow, and Redux
| introduced centralized state which was a massive
| improvement over AngularJS.
| petilon wrote:
| > _but the style of programming it introduced to many millions
| of web developers made a sizeable chunk of them interested in
| fp_
|
| Why would that be? React is not functional, and the style of
| programming has nothing to do with functional programming. It
| is fundamentally inconsistent with functional programming.
| thinkharderdev wrote:
| Indeed. I would add as well that React (for me at least) went a
| long way towards erasing the difference between "backend" and
| "frontend" development. When I was a pup, they were very
| different things and a "frontend" developer meant basically
| someone who was really good at CSS and HTML and new all the
| magic incantations you had to do to create a nice UI with them.
| There were of course precursors such as AngularJS (and others)
| but React was really the first one for me where I could see
| frontend dev as just learning another framework the same as I
| would learn a backend framework.
| bricss wrote:
| The only good thing about it, it's JSX! \m/ The rest is
| abomination !_!
| outside1234 wrote:
| Congrats Dan and everyone on the React team. Great framework and
| has been an extremely productive decade for me personally.
| kamaal wrote:
| As a backend developer who didn't 'get' web development for many
| years. Learning react changed all of it. React was revolutionary,
| and just clicked for me. Combine this with frameworks like
| Material UI, Patternfly and many others and its almost like you
| have some super power. These days I can build fairly big sites
| with lots of stateful components quickly.
|
| Most of my use cases is to build internal tools. But the pace
| with which once build things in react and its over intuitiveness
| just makes it special.
|
| React is one framework which Im sure will be available for long
| time to come!
|
| Thank you React dev team.
| plugin-baby wrote:
| Similar feelings here. To me, React was one of the first
| approaches to web frontend development that really promoted
| good engineering practices.
| rchaud wrote:
| As someone who started in front-end and was deluged with 2000s
| conventional wisdom like "don't use inline styles" and "keep
| scripts separate from your CSS and HTML markup", React made
| absolutely no sense.
| june_twenty wrote:
| Embrace it for awhile and it really is special.
|
| You've a function that returns JSX which is your HTML where
| you can use Javascript to reference functions/variables (e.g.
| the state variables)
|
| One of the key parts is that you can break it all down into
| different files/functions that return jsx so you can isolate
| complicated parts
| Zetice wrote:
| Agreed. There's a "before I knew React" and "After I knew
| React" bifurcation of my career.
|
| Before, I could call myself a "full stack dev" because I could
| cobble together a site with JS, but it wasn't pretty. It didn't
| follow any real conventions, was a nightmare to maintain,
| forget about testing, etc.
|
| After learning React, I actually can _design_ , and structure
| the code in a logical way. Testing is a lot simpler, code reuse
| makes sense... it created a mental framework on which I could
| translate my ideas into usable code that pattern matched to how
| I was used to building code for the backend.
|
| I will never feel like I'm a "frontend dev", but I don't need
| to be. I can take an idea, and turn it into a functioning
| service, and isn't that all we're here to do anyway?
| revskill wrote:
| 10 years and state management is still a mess.
| latchkey wrote:
| I'd say it is less about being a mess and more about the fact
| that there are 1000 projects that do state management in
| totally different ways and it is nearly impossible to figure
| out which one to use. Even if you pick one, you don't find out
| that it has some critical bug until you're half way through
| your project and it is too late to swap it out. So, you end up
| coming up with some hacky workaround that creates a lot of
| brittle code and breaks every time you upgrade some other non-
| related component of your application.
| adverbly wrote:
| Finally all those job postings asking for 10 years of React
| experience can be filled!
| memonkey wrote:
| I have been using React for almost those 10 years. When I first
| started out, I was writing Java for Android. I then got a
| contract position writing AngularJS 1.2. A couple years later,
| Angular 2 would be released but by then I was already beginning
| to write small React apps. I also made a small app with React
| Native for an audio company. By 2016 I was working at a popular
| Fortune 100 company on the first team to migrate their existing
| JSPs to React. By the time I left that place, React Hooks were in
| beta and gaining steam. I was lucky enough to work with a
| Facebook Alumni who hated React, so we used Vue. It felt like a
| more opinionated React in some cases, but I really enjoyed the
| experience. Now I'm back to React and a lot of the same problems
| exist. Some things are just hard or extremely tedious to do. Some
| places rely heavily on external libraries which cause so much
| bloat to the system it can feel slow (even when it's not). Most
| places I have been to are extremely opinionated about how their
| app is built, despite it being the same thing (for example, there
| are 20 different ways to build an e-commerce site). But the
| places I have enjoyed the most had a hackerish culture, so people
| weren't insanely opinionated so long as you got the job done,
| which I feel like React is great for. I have unfortunately not
| used NextJS, but I have used Nuxt which has been wonderful. I'm
| semi in between jobs right now and have been looking at potential
| offerings, and I haven't seen a huge need for these frameworks
| yet. If NextJS is anything like Nuxt, I think I'd be happy to
| work in them. But I may also look for the places that offer a
| completely new experience.
| theironhammer wrote:
| SolidJS? It uses Signals in its Reactivity system and there's
| no virtual DOM. It has some syntax similarities to React making
| it easier to transition. It uses JSX and is quite performant.
| steve_adams_86 wrote:
| I love Solid. In the last month or so I went from curious to
| fairly certain I'd prefer to work with it over React.
|
| I'd used it before to trial it and explore differences, but
| never actually built something. I used it with XState (state
| charts) to build a version of Minesweeper which uses the
| receptionist pattern to orchestrate actors, which was
| pleasantly unnecessary, and I really loved it.
|
| Although I have around 8 years of experience with React,
| Solid somehow made the process easier in some regards. React
| -- despite being excellent in many ways -- has a few sneaky
| foot guns that I still manage to wander into when trying new
| tools and patterns. Solid on the other hand was quite
| friendly. Ironing out anticipated performance issues was
| mostly an idea and never became necessary. In React I did
| need to tidy up some redundant renders and fix state
| synchronization due to out of sync effects.
|
| I'm currently job searching and totally wouldn't hesitate to
| work with a team that uses Solid. But, React is good too. At
| the end of the day I just love making things people enjoy
| using.
| koinedad wrote:
| React - you have a special place in my heart
| cloudyporpoise wrote:
| So now all those ridiculous job postings requiring 10 years
| experience with React finally make sense?
| revskill wrote:
| It should be 15 years of experience now.
| ggregoire wrote:
| As someone who worked with jQuery (15 years ago), then
| Backbone.js, then Angular 1, then React (for the last 6 years or
| so), I honestly feel like React is here to stay. It solved all
| the pain points I had with the previous frameworks when working
| on complex and massive code base. I have a level of productivity
| I never achieved before. I never have to check the docs, I can't
| remember last time I thought to myself "why is this not working"
| or "how am I going to do that" or "what's the syntax/arguments of
| X". It is amazingly simple, intuitive and powerful. Most of the
| time I'm just reusing components I coded years ago, gluing them
| together to develop a new app that would have taken me days with
| the previous frameworks.
| nailer wrote:
| > As someone who worked with jQuery (15 years ago), then
| Backbone.js, then Angular 1, then React (for the last 6 years
| or so), I honestly feel like React is here to stay.
|
| That sentence didn't end how I expected it to. Personally -
| coming from a similar (jQuery -> Knockout > Backbone > Ember >
| Angular 1 > React > Svelte) background - I feel React has gone
| the same route as the others - rose quicky, dominated, and will
| never go away, but no longer has any influence. The same will
| happen to Svelte in future.
| graftak wrote:
| React still has some tricks up it's sleeve with great
| potential that are (often) missing in comparable frameworks.
| Error boundaries, async (server) components, suspense,
| portals, dynamically imported components, concurrent mode.
| Just a shame it takes/took forever for suspense to resolve.
| brundolf wrote:
| Can we agree it's not a "framework du jour" anymore? 10 years is
| a pretty long day
| garganzol wrote:
| React is a text-book example of what a well-designed component
| model can do to a development cycle: a literal 5-20x productivity
| boost compared to the old vanilla JavaScript with jQuery and
| manual HTML manipulation.
|
| I was somewhat skeptical in the early days of React, but once
| static websites with rehydration became a thing, I was fully in.
| So much power.
| petilon wrote:
| > _a literal 5-20x productivity boost_
|
| Not really. See a better way here:
| https://github.com/wisercoder/eureka
| capableweb wrote:
| Looks like MVC/MVVC, something that has been available to do
| in JS since long time ago (Backbone.js was a popular option
| for doing a modified version of this). Or I'm missing
| something obvious. Care to explain a bit more in detail?
| petilon wrote:
| Backbone.js used 2-way data binding. Some people mistakenly
| think MVC implies 2-way data binding. It does not.
|
| The point here is that you can write maintainable, clean,
| efficient JavaScript web apps without the load of
| complexity added by React.
| yazaddaruvala wrote:
| Sorry, I don't understand. Why is this a relevant link?
|
| "Lucene based search" vs React ? Seems like comparing trees
| to tractors.
| petilon wrote:
| See the web app. It is a more productive style of coding.
| Simple, and no need to deal with hooks and useState and
| useContext and none of that nonsense.
| yazaddaruvala wrote:
| Got it thanks for the context.
|
| I've read the web app and it seems to me it is just
| https://backbonejs.org/ re-written in Typescript and
| allows JSX.
|
| I'm very certain Typescript and JSX will have improved
| the DX for Backbone like apps, but it doesn't address all
| of the other issues that teams had with Backbone.
|
| e.g. Cyclical event propagation, state stored in the DOM
| (i.e. appendChild is error prone in large multi-person
| code bases), etc.
|
| FWIW, the reason this works for eureka is highlighted
| best on this page:
| https://github.com/wisercoder/eureka/graphs/contributors
| there is only a single author!
| petilon wrote:
| There is no two-way data binding in use here, so you're
| wrong.
|
| The style used is MVC. Do you think MVC is not suitable
| for multi-person teams? If so how do you explain MVC in
| Cocoa, ASP.NET Core, JSP and JSF, Ruby on Rails, and
| Django (Python)? They are all based on MVC.
| MuffinFlavored wrote:
| I feel like there are 2 Reacts (at least 2 that I know of, if not
| more).
|
| I learned jQuery long ago, then how to get most of what I wanted
| done via document.querySelector/etc instead since it was more
| "lightweight", then I learned React "class components" with
| render() and componentWillMount() and it was a big leap forward.
|
| The "major breaking changes" (semantic versioning wise) to move
| components to functions (instead of implying it's just a class
| with render()) and then hooks on top, it almost invalidates most
| of what I learned about React initially. Which is fine. The
| community reserves the right to grow however they want. I was
| just surprised when I recently revisited it. The only common
| concept was basically JSX and "view/render state/props + actions
| on events".
|
| I don't think many would agree to this but I'd argue the changes
| are so radical that they almost should've called this new React
| something entirely different. It would help. Saying "I know
| React/I have React experience" is basically in need of nuance
| like "I have React in 2018 experience, and 0 React in 2023
| experience, therefore I don't actively/actually know current
| React best practices or how to even do a small TODO hello world
| list example".
| Capricorn2481 wrote:
| There are no breaking changes. Class components are still
| supported and used at Facebook
| pier25 wrote:
| Class components are deprecated. They only appear in the
| legacy section of the reference.
|
| https://react.dev/reference/react/legacy
| rozenmd wrote:
| > These APIs are exported from the react package
|
| You can still write React the old way.
| trgn wrote:
| Sure. But search anything about React, and you'll see
| examples in hooks.
|
| I don't even understand the reason why class-based is
| "legacy". Why are hooks inherently better? Code-reuse is
| a factoring concern, not a paradigm concern. And
| component-life-cycle bugs are now replaced with nearly
| impossible to understand callback stacktraces.
| williamstein wrote:
| Minor correction -- It seems like the page you link to has
| two sections: Legacy APIs and Deprecated APIs. Class
| components are not deprecated; instead, they are in the
| legacy section. The only thing that is listed as deprecated
| in the page you link to is "createFactory -- lets you
| create a function that produces React elements of a certain
| type."
| andrewmcwatters wrote:
| Oh also certain concepts and strategies are only written
| about in the legacy documentation. Good luck new devs!
| zoover2020 wrote:
| Reminds me of a React V11 codebase at work. It is bad
| enough that I always include it as a heads up during our
| scoping, as in: "double your estimates because the
| version of React is so old"
| june_twenty wrote:
| happens to lots of stuff and is not react specific
| c-hendricks wrote:
| Care to source/link them? You obviously think they're
| important so you should do some good and share!
| andrewmcwatters wrote:
| New docs don't tell you how to get a minimal start
| anymore. You MUST fully commit to a create-react-app flow
| or similar, or they vaguely point you in the direction of
| Babel without explicit direction.
|
| The formal way of using React and JSX without a full SPA
| framework is only listed here:
| https://legacy.reactjs.org/docs/add-react-to-a-
| website.html
| c-hendricks wrote:
| Ah, I guess you're referring to how they're pushing
| frameworks over bundlers?
|
| > If you want to build a new app or a new website fully
| with React, we recommend picking one of the React-powered
| frameworks popular in the community. Frameworks provide
| features that most apps and sites eventually need,
| including routing, data fetching, and generating HTML.
|
| > Grab react and react-dom from npm, set up your custom
| build process with a bundler like Vite or Parcel, and add
| other tools as you need them for routing, static
| generation or server-side rendering, and more.
|
| https://react.dev/learn/start-a-new-react-project#can-i-
| use-...
| tracker1 wrote:
| Getting started with parcel is pretty damned straight
| forward.
|
| https://parceljs.org/recipes/react/
| tunesmith wrote:
| I sometimes feel like there are three. The class components
| way, the hooks way that everyone has been doing it up until a
| few months ago, and the hooks way that the beta docs say you
| should do it. Maybe those last two aren't different enough, but
| the clashing philosophies around useEffect are enough to
| require massive refactors.
|
| EDIT: I'm referring to how the proper use of useEffects is to
| almost never use them. They're for side effects, and they're
| not a tool to just "re-render when these dependencies change".
| But to do this right, it requires a re-wiring of the mental
| model of how to do React, at least for many people I've come
| across.
| Apotheos wrote:
| What's the new way as of a few months ago? The docs way?
| rkuykendall-com wrote:
| They may be referring to React 18 + Strict Mode meaning all
| useEffects can be called as many times as React wants.
| People before were writing code where useEffect on []
| worked like onMount and was only called once.
| Kiro wrote:
| Then how do I emulate onMount now?
| q7xvh97o2pDhNrh wrote:
| The entire hooks "thing" felt like a case of the library
| authors being too clever.
|
| Having components with lifecycle methods called at known
| times by the framework is a perfectly straightforward
| mental model. It's worked just fine since the beginning
| of time. iOS _still_ uses it.
|
| I remember investing hours (and days and weeks) migrating
| old code to the "new way" or trying to get some simple
| thing "working with hooks." Other than being able to
| share in the authors' feeling of smugness over the
| unnecessarily-convoluted mental model when we finally got
| it all working, I genuinely can't recall any value we got
| out of the whole investment.
| dboreham wrote:
| It turns out much of s/w development is a cult (many
| cults) with no basis for their teachings.
| flashback2199 wrote:
| I agree. Hooks felt to me like an attempt to go all-in on
| functional programming when components are perhaps easier
| for many people to think about as classes due to the
| unavoidable need to have state in the component. It
| seemed like an attempt at purism that, instead of making
| things simpler, made them, at least cognitively, a bit
| more complicated due to the irreducible complexity of
| state.
| Izkata wrote:
| > Having components with lifecycle methods called at
| known times by the framework is a perfectly
| straightforward mental model. It's worked just fine since
| the beginning of time. iOS still uses it.
|
| Android, too.
| andrewmcwatters wrote:
| What's so infuriating about that is the documentation
| basically told people, hey instead of doing this, use
| useEffect the way you were using these methods.
|
| So are the users wrong, or did you screw up?
| ihateolives wrote:
| > So are the users wrong, or did you screw up?
|
| When you have to rewrite the documentation to basically
| tell the world "you're holding it wrong" then it says a
| lot about the thought that has (not) gone into designing
| the feature.
|
| And that's why I think I'm done with React for now. It
| just does not spark joy.
| [deleted]
| c-hendricks wrote:
| If you're ignoring dependencies that should be on a call
| to `useEffect`, you're just making room for bugs.
|
| If you're not properly tearing down what you're doing in
| an effect, you're just making room for bugs.
|
| These have always been true of useEffect.
| [deleted]
| brundolf wrote:
| I think the "new way" was always the intent. If the past norm
| is different, it was probably a communication issue (which
| the beta docs are trying to address)
| tunesmith wrote:
| I'd agree.
|
| I haven't tried asking GPT4 a bunch of react questions yet.
| I wonder if its advice is generally in accordance with the
| "new way", given the training data cutoff date.
| nop_slide wrote:
| What are the clashing philosophies?
| cjauvin wrote:
| I'm not sure about the clashing philosophies, but useEffect
| is certainly a "nexus of difficulties" about learning and
| using React (with hooks), in terms of the mental model it
| requires, knowledge of not-so-obvious JS concepts like
| closures, etc..
| rimunroe wrote:
| This isn't a recent development. People misusing useEffect
| just to update state has been a thing in React since they
| were introduced, even though a close reading of the original
| hooks docs should have conveyed that that's not what they're
| for. I think the new docs certainly make it clearer what the
| correct usage is, so now lots of people are finding out that
| their mental model isn't quite right.
|
| Some of this predates the introduction of hooks, as much of
| the useEffect misuse is identical to the way people misused
| componentDidMount/componentDidUpdate/componentWillUnmount.
|
| I don't think you're right to say that you should almost
| never use them. You _should_ use them for doing the things
| which they 're designed for, like attaching event listeners
| or dealing with timers (neither of which are that unusual in
| my experience). But like I said, they've never been a tool
| for dealing with rerenders, and the React team has been
| trying to explain this to people for ages. The original docs
| did explain this, but it was less clear than the new ones.
| franciscop wrote:
| Exactly, this is the same as saying Redux has two
| methodologies, the "setter system" and the "event system";
| since it wasn't that well documented initially doesn't mean
| that the setter way was ever recommended (it's not). In
| fact if you watched the Flux youtube talk, something highly
| recommended to learn the philosophy behind Redux, it was
| pretty clear.
|
| Edit: here's the video (from 10:20)
| https://www.youtube.com/watch?v=nYkdrAPrdcw
| devjab wrote:
| I think it's more a matter of how the JS community has grown in
| general. The whole "class" thing is something a lot of us
| brought into it when we came from other OOP languages, but in
| 2023 it is very rare that it is "better" to build a "class"
| than to simply build the functions you need.
|
| As far as I know you can still trundle on with some of the old
| react, but at the same time, things change. It's not like
| you're coding C# similar to how you were 10 years ago either. I
| know that having been away from it, it was interesting to see
| everyone using "var" instead of types as an example.
| dboreham wrote:
| OOP was invented to capture patterns already widely used in
| assembler and C and other old languages.
| andrewmcwatters wrote:
| Classes and types and methods exist for a reason. They're not
| "old" you don't "grow beyond them" anymore than you "grow
| beyond" functions, constants, threads, or files.
|
| Try stepping outside of JavaScript for a while, broaden your
| experience.
| c-hendricks wrote:
| So you're just gonna ignore that whole "the JS community"
| bit then, ok.
|
| Is this what $200/hour consultancy looks like?
| andrewmcwatters wrote:
| Try writing some code in not just JavaScript but also C,
| C++, Java, and others. Classes aren't some relic. You use
| prototypes in JavaScript every single day.
| c-hendricks wrote:
| You're still just blowing past "the JS community".
|
| To fill you in on the context of the thread you inserted
| yourself into, classes have fallen out of favour _in JS_.
| It's pointless to say "but they're still used in other
| languages!" because we're not talking about other
| languages, we're talking about JS.
| andrewmcwatters wrote:
| I, too, am talking about JavaScript. Everything in
| JavaScript is prototype-oriented whether you ignore it or
| not.
|
| You can choose to write functions for everything, but
| you're still always using object prototypes.
|
| There are several large popular libraries in JavaScript
| which do not orient themselves around functional object
| orientation, too. So you might work in one corner of
| JavaScript where all you experience is functions, but
| that's not the case everywhere.
|
| They haven't "fallen out of favor," whatever that means.
| devjab wrote:
| I think we may be talking a little bit in two different
| directions, because when you write this:
|
| > Classes and types and methods exist for a reason.
|
| What that reads like to me is actually the exact
| explanation as to why the JS community has fallen out of
| love with things like classes. Because JS doesn't have
| static types, and without those, well... Classes don't
| actually exist. At least not in the way they do in other
| languages like C++. You can pretend you're working in a
| regular OOP language, and use the prototype object like you
| would a C# or Java class but since you don't have static
| dispatch at compile time, you're frankly playing this part
| of JS as a weakness instead of a strength.
|
| Which is why the JS community has been "growing beyond"
| classes.
|
| If working with classes in JS is more comfortable for you,
| then I think you should do so, but ultimately a JS class is
| just a function. Once you grow comfortable with working
| with modules and functions, you're very rarely going to be
| writing classes when working with JavaScript. You're still
| going to do so from time to time, when it makes sense, but
| often its both unnecessary, less efficient and harder to
| maintain something that is build like a C++ class rather
| than than a JavaScript function. While working with
| JavaScript, being a key part of it. This is not an attack
| on OOP in general, just an explanation as to why the JS
| community has "moved beyond" pretending JS is an OOP
| language the same way Java is an OOP language.
|
| > Try stepping outside of JavaScript for a while, broaden
| your experience.
|
| I do so regularly.
| andrewmcwatters wrote:
| A JavaScript class is syntactic sugar for prototypes, not
| functions.
|
| JavaScript is a prototype-oriented language.
| devjab wrote:
| > A JavaScript class is syntactic sugar for prototypes,
| not functions.
|
| Again you're basically speaking into exactly what I'm
| trying to say. Because what are JavaScript functions? It
| is also a prototype. I'll try to put it a different way.
| The JS community has "moved beyond" classes because they
| are functions. Both classes and functions are prototypes,
| but functions are often easier to work with, more
| maintainable and more efficient.
|
| I'm not trying to say that you should never write another
| JavaScript class in your life. I write them myself when
| it's prudent to build things in a structure that
| resembles classical OOP. The reason I don't personally
| use that sort of coding style, if I can avoid it, is
| because it's an act. It looks like classical OOP, but
| everything is mutable at any time which means it's very
| easy for consumers of the code to break it by accident.
| This is less of a problem when you build things as
| isolated modules, based on individual functions, because
| there simply isn't any complexity to "misuse".
|
| This is sort of similar to why the virtual DOM became so
| popular in frontend JavaScript. Because it's harder to
| work directly with the DOM itself. It's not necessarily
| better to use functions, it's just "safer", because they
| come with less risk of someone doing something bad by
| accident down the line.
| fendy3002 wrote:
| Uhh yes, classes in JS is just function, but it forces
| you to make a strict definition on how the set of
| functions will behave, in opposite of defining functions
| and tied them up individually.
|
| If a thing need properties and methods to operate,
| defining it as class won't make it harder to maintain
| than cleverly do it with functions and object.
| tracker1 wrote:
| It's slightly more now with private members, but still
| prototype based inheritance and definitely not the same.
| Composition will still usually perform better all said.
|
| If you want something more, better to use TypeScript or
| step to something like Rust+Wasm.
| devjab wrote:
| > but it forces you to make a strict definition on how
| the set of functions will behave
|
| This would be true if JavaScript had static dispatch, but
| since it doesn't, everything you do with your class is
| mutable all the way up the prototype object chain. One of
| the reasons this is harder to maintain, is because the
| "strictness" you think you build into your code isn't
| actually there unless everyone who works on your code
| after you follows the same rules you did. I'm sure we'd
| like to live in that world, but I doubt we will.
| lumb63 wrote:
| I believe OOP is generally overused (no, you don't need a
| zero-member class to provide related functions; static class
| members are a code smell; etc.), but I don't follow what
| you're saying. From my perspective as someone who is just
| learning React recently but has a decade's experience in C,
| C++, and Rust, the programming model doesn't make any sense
| to me. The functional paradigm used by React has the same
| fatal flaw as OOP does: rather than making state management
| simpler, it attempts to hide it (OOP hides by "private"
| variables, React chooses to hide it in "hooks"). Both seem
| absurdly complicated to me. There's no need for classes with
| trivial setX() methods, and there's no need for hooks either,
| to perform what is essentially a variable assignment. They
| make the code more complicated to read and write, and
| increase cognitive load, IMO.
|
| A component that has some state associated with it, such that
| manipulating that state causes certain side effects, seems
| almost custom-fit for OOP. The functional style does not seem
| to fit the domain.
| rektide wrote:
| Yeah. Functional components are right sized. You can still
| decompose & hack off pieces nicely, into helpers or hooks.
|
| Just because CS has heavier weight classical structures we
| can apply doesn't mean they're better. And underneath a lot
| of those ideas were more lambda-calculus ideas that
| correspond somewhat with functional components.
| yamtaddle wrote:
| I dunno... when you're building a _hierarchical tree_ of
| _nameable components_ and several, ahem, _instances_ of each
| nameable component might exist, and these need to respond to
| _signals_ , that seems like a case when it's non-crazy to use
| classes.
| [deleted]
| paulddraper wrote:
| Akin to JS replacing callbacks with async/await:
|
| 1. You can use both styles, even interchangeably.
|
| 2. The latter is superior.
|
| Async/await allows you to write asynchronous code in a
| synchronous style.
|
| Hooks allow you to write stateful code in a stateless style.
| pier25 wrote:
| > _I don 't think many would agree to this but I'd argue the
| changes are so radical that they almost should've called this
| new React something entirely different._
|
| Absolutely and I've been saying the same thing for years.
|
| IMO it was an extremely irresponsible thing to do considering
| React is critical infrastructure at this point. And by
| completely changing the methodology they made obsolete A LOT of
| educational content (books, tutorials, videos, etc) in an
| instant. I'm sure people making money of React education were
| very happy with this.
|
| Don't get me wrong, I'm not against evolution. But if you're
| going to make such a drastic change just create a new project.
| Plus I wonder what other improvements/changes they could have
| made if they had started from scratch.
| ipaddr wrote:
| In the words of succession. This is not a serious product.
| davedx wrote:
| Nobody is forcing you to use it.
|
| The react devs made a bunch of code migration tools, used
| semantic versioning, slowly deprecated old APIs over multiple
| versions, maintained vids and documentation. Honestly
| compared with some projects they handled the changes and
| evolution of the API extremely responsibly.
| pier25 wrote:
| Yeah maybe, so? That's really not what I'm arguing about.
| tacheiordache wrote:
| > Nobody is forcing you to use it.
|
| Nobody is talking about that. Instead is about how these
| changes could be done without creating so much confusion in
| the community. In fact people embrace evolution of these
| frameworks but with clear changes in methodology, labeled
| as such and so on.
| beders wrote:
| > Nobody is forcing you to use it.
|
| This argument goes out the door if you need to adopt a
| library that has already adopting them.
|
| Even reagent, an extremely conservative React wrapper, had
| to provide support for functional components, hooks and
| effects eventually.
| andrewmcwatters wrote:
| People _are_ forcing you to use it. It 's called
| employment.
|
| God forbid you're a principal running into some junior
| engineers and they don't understand that you've forgotten
| more than they know, and the migration to functional
| components is just another part of your extended career
| timeline.
| orangepanda wrote:
| Does anyone seriously expect nothing to change and
| improve for 30 years, or however long their career is?
| Not just in software, but any profession. Long gone are
| the days when the same plow is used for 10 generations.
|
| From my experience its not learning something new thats a
| problem, but getting the organisational support to push a
| major change through
| plugin-baby wrote:
| If you're a principal, just ask your juniors to explain
| their useEffect()-based mess. When they can't, mandate
| class components.
| trgn wrote:
| I upvoted because yes.
|
| in practice, pick your battles.
|
| Also then in practice, you'll get people shrugging off
| their hooks get called 10 times iso 1. then maybe add
| useMemo everywhere just to be sure. Hmm.. still kind of
| weird. Maybe sprinkle in some more if-thens, that will
| fix it! Deep breaths..
| dynamite-ready wrote:
| This is the true legacy of React, and it's awful. It's
| not just a case of "you're doing it wrong", because even
| cutting edge codebases (developed in the last 1 or so)
| are struggling with this.
|
| "useMemo is the solution" many will tell you. Compared to
| the way things are handled in Vue, useCallback and
| useMemo are near enough code smells for something rotting
| in the center of the React codebase.
| ipaddr wrote:
| Then you get a security audit that you are not using the
| latest whatever and c-suites panic
| yazaddaruvala wrote:
| If you're a principal, you should be able to keep up with
| modern tools. Making sure the engineers around you are as
| productive as possible with their current tools and
| processes is literally your job!
|
| If as a principal, you are no longer able to keep up with
| tooling / patterns that everyone else at your company
| wants to use, its time to take a smaller scope or time to
| retire.
|
| The job, including mandates (if any are needed) is to
| empower the people you work with, not to stifle them.
| kdrag0n wrote:
| React Server Components (RSC) feels like the third React.
|
| https://nextjs.org/docs/getting-started/react-essentials
| __float wrote:
| I'm not sure I agree with this. It's "different" in that you
| don't need to learn the intricacies of some new data loading
| and state management library (we've seen _so many_ of these
| over the years!). But the concepts themselves are much closer
| to "just plain React".
| nawgz wrote:
| I fully disagree. It's the exact same internal mechanisms
| lending themselves identically to rerender semantics and so on.
| They were exposed with new names and access methods, but
| enabled you to perform virtually the same component update
| logics, except with a few antipatterns made more difficult.
| HOWEVER it is also fully backwards compatible, you can run
| these old versions.
|
| So, what stayed the same?
|
| * Could still use classes
|
| * Still had the same props & state semantics
|
| * Components still could own state and receive props
|
| * Some renamed code paths were used, a couple of the
| "componentShouldRender" style ones were dropped to prevent
| programmers making fatal errors
|
| * Still wrote the same markup
|
| * Still could use the same libraries
|
| I never really understand this complaint; React achieved gold
| standard backwards compat. Either that or my 2016 era tools
| building in 2023 on the newest React with old ass libraries
| would've caused a lot more pain points!
| shams93 wrote:
| This is a kind of career violence intentional radical constant
| change such that experience doesn't matter maybe those of us
| pushed out of industry over react should hit meta with a
| lawsuit.
| SketchySeaBeast wrote:
| I can't tell - is this satire? Good faithing it - this could
| only be (partially) valid if the old ways didn't work, which
| they still do. If you've been pushed out, you haven't been
| pushed out of the industry because of the change.
| baron816 wrote:
| > I was just surprised when I recently revisited it.
|
| You can STILL write React like you used to (with class
| components). There haven't been any major breaking changes. The
| transition was very slow. It was only recently that they even
| changed the docs.
|
| You're complaining that they made changes to it half its
| lifetime ago after you walked away from it and now you can't
| just go back to the way it was.
| pier25 wrote:
| > _You're complaining that they made changes to it half its
| lifetime ago after you walked away from it and now you can't
| just go back to the way it was._
|
| Wouldn't you expect jQuery to keep using the same fundamental
| methodology a couple of years later?
| bobthepanda wrote:
| I mean, Java was the stereotype of boring enterprise
| language, and has certainly changed a lot in the last ten
| years in terms of its shift towards functional-friendly
| programming.
| pier25 wrote:
| How is this even comparable?
|
| Not only React changed completely almost overnight, but
| the changes in the methodology were fundamental.
| baron816 wrote:
| This is just blatantly untrue. The changes were
| definitely not overnight. Not even close. You're still
| free to write React in the old way. The docs were there
| for half a decade.
|
| If they had just made a different project, we'd still be
| talking about the same thing. You would still be
| complaining that things changed and you didn't feel like
| bothering to learn a new thing.
| bobthepanda wrote:
| So are the Java 8 changes? Java lambda functions, streams
| and futures look nothing at all like traditional Java
| methods and threads, yet you're still free to write them,
| but nearly every Java Stack Overflow question has a
| dedicated Java 8+ answer because it is so different.
| bcrosby95 wrote:
| Note that Java futures are from 2004. By the time Java 8
| rolled around they definitely were "traditional".
|
| But lambdas and everything coming in project amber, yeah,
| there will increasingly be many styles of Java out there.
| yazaddaruvala wrote:
| > By the time Java 8 rolled around they definitely were
| "traditional".
|
| Based on my experience only once CompletableFuture was
| added to Java did the Future interface really start
| getting used in mass. Before that, there were other libs
| that implemented Future like things (Rx, Guava, Netty,
| etc) but they were not adopted across the board.
|
| The transition to Java 8 was night and day! Roughly on
| par with the React Hooks transition.
| kokanee wrote:
| Sure, React still supports that, for some reason. But good
| luck getting a job offer or even a PR approved if you're
| using `this.setState()` in 2023.
| trgn wrote:
| Shame. Simple class-based React-components are joy to work
| with. Flat code layout, simple life-cycle, no new semantics
| to learn ("rules of hook"), no crufty mem-allocation.
|
| I firmly believe that FP-seepage into web programming is
| one of the reasons why so many web apps are so slow and
| feel sluggish, jittery.
| kokanee wrote:
| The great downfall of hooks, IMO, is that they allow you
| to create components that look clean and legible, but act
| unpredictably because all of your state updates are
| triggered by variable reference changes. The idea is that
| this makes your state updates happen automagically so you
| don't have to think about them, but this is a classic
| example of an abstraction that works until it doesn't.
|
| Redux mainstreamed the concept of reference changes
| triggering updates, but I think this is a horrible
| pattern - we don't even have an operator in JS for
| explicitly passing by reference, so you end up
| destructuring large objects constantly in order to change
| one property and create a new object reference, which is
| a totally inefficient alternative to calling a render
| method. Plus javascript developers don't generally think
| about the concept of passing by reference vs value
| anyway, in large part because the language gives us so
| few tools for making those choices.
|
| As a result, there is a class of bugs where the only
| solution is to change the list of dependency variables
| for a given hook. It doesn't take a huge amount of
| complexity for the implications of those dependency trees
| to bend the mind, and the "clean" syntax of hooks comes
| crashing down.
| Izkata wrote:
| I can't speak in general, but there is one thing I
| vaguely remember being on the React roadmap as part of
| the class->function switch that AFAIK never happened (at
| least it hadn't last time I did a lot of React, which was
| years into the switch): Because they were pure functions
| based on props, React-the-framework would have the class-
| based shouldComponentUpdate built into it and using
| function-based components everywhere would get a free
| performance boost.
|
| Instead nowadays people who started with the function
| form don't know shouldComponentUpdate ever existed and
| all their React components constantly rerender.
| butterfi wrote:
| This is such a common problem these days. I have almost 15
| years of experience with another framework, but the latest
| iteration is almost a complete re-write and most of what I knew
| in the past isn't that helpful. To say I have "x" years of
| experience doesn't really acknowledge my current level of
| understanding.
| nfRfqX5n wrote:
| the core concepts are the same. the implementation details have
| changed, but I think it's a stretch to call it a radical
| change. you could probably learn how to convert a component
| from class -> functional in a few hours.
| frou_dh wrote:
| Is it really that much of a crisis to have the "0 React in 2023
| experience ... don't even know the modern hello world" when one
| can just spend some time on their (excellent) documentation
| site and get back up to speed?
| chilmers wrote:
| 10 years, and yet any discussion on this site about front-end
| development will be filled with people complaining about how
| front-end development practices change too quickly.
| yamtaddle wrote:
| React development has had _multiple_ major changes over that
| time span, as far as what 's culturally allowed & encountered
| in the wild (if not what's technically possible). Just-
| functions, classes-and-functions mixed as appropriate, redux
| becoming a nigh-standard, the HOF invasion, hooks, and classes
| becoming deprecated.
| pastor_bob wrote:
| 10 years old and the only reliable official docs on how to use
| react came out just 2 months ago:
| https://react.dev/blog/2023/03/16/introducing-react-dev
| ksherlock wrote:
| They had a tutorial and reference 10 years ago:
|
| https://web.archive.org/web/20130607112825/http://facebook.g.
| ..
| dlisboa wrote:
| There's still truth to that. React has changed a lot in those
| 10 years. So much so that old code is unrecognizable and would
| be an anti-pattern today.
|
| And that's only React, the ecosystem around it also has changed
| significantly.
| karaterobot wrote:
| To be fair, React itself has changed in fundamental ways
| multiple times throughout that period. And it's not like React
| is the only thing you need to worry about when building a React
| app: there's a whole ecosystem of tooling and libraries that
| you rely on which are constantly moving.
| SenHeng wrote:
| What common, popular and highly used technology hasn't
| radically changed in the last decade?
|
| Back in 2015, $JOB was evaluating upgrading Java 6 to Java 7
| or 8. What is now? 20?
|
| I last touched php in 2012, which was 5.4 or 5.5 I think.
| People were still arguing that Laravel couldn't replace
| CodeIgnitor, or that we should stick with Symphony or Zend.
|
| Change is the only constant. In that respect, React has been
| relatively sane.
| karaterobot wrote:
| As you know, Java and PHP are languages. React is just a
| framework, and by design not a particularly robust one on
| its own. It just provides a front end, everything else has
| to be plugged in separately, learned, maintained, and
| ultimately cast aside and forgotten separately.
|
| If you're a React developer, you'll have noticed that
| Javascript itself has changed a lot in ten years. The state
| management library your company uses has probably changed
| too. Compared to ten years ago, you're now writing fully-
| typed JS with Typescript. The additional libraries for
| authentication and persistence, and so on, have all changed
| as well. You may be using a graph-based database now. You
| may have a different JS runtime on the server. All of your
| tooling has probably changed, as has your IDE.
|
| Whether React itself has or has not changed more than other
| frameworks, I can't say. But, I'd bet the stack used by the
| average front end developer has. Please recall that the
| original comment we're both talking about was referring to
| complaints about how much the _front end_ has changed, with
| React only being the context of the comment, and not the
| sole cause of the complaint.
| yazaddaruvala wrote:
| > As you know, Java and PHP are languages. React is just
| a framework,
|
| Ok then, what about the Spring .xml to .java migration?
| What about the Struts -> Struts2 -> SpringMVC ->
| SpringWebapp migrations.
|
| It seems an unfair criticism of React.
| lmm wrote:
| > Ok then, what about the Spring .xml to .java migration?
| What about the Struts -> Struts2 -> SpringMVC ->
| SpringWebapp migrations.
|
| When I started my first programming job 14 years ago xml
| was already not recommended and SpringMVC was already the
| way of doing things. So that's quite a bit stabler and
| slower than React.
| lmm wrote:
| > Back in 2015, $JOB was evaluating upgrading Java 6 to
| Java 7 or 8. What is now? 20?
|
| And how much have you had to rewrite or replace going from
| 8 to 20? Very little, right?
| beders wrote:
| 10 years and we are still building custom forms from the same
| primitive building blocks.
|
| And with react having to fudge with the state of DOM input
| components, it's been a messy ride.
|
| And yet, the idea of describing your UI and have a library figure
| out what needs to be repainted has been liberating. React
| certainly wasn't the first, but it certainly was the most elegant
| one at the time.
|
| I wish React would split up and go back to the roots: Have it
| deal with rendering - and nothing else.
|
| Have optional companion projects that deal with the various forms
| of state and side-fx.
| latchkey wrote:
| I've been maintaining a project for 4 years now (~40k
| downloads/mo on NPM, 400+ stars) that is simply glue code
| between a React form management library and a React UI library.
| It was really hard to get right, still isn't perfect, and over
| the years has required several major upgrades to keep up with
| changes in all three. Luckily, I have very good unit tests and
| snapshots that ensure upgrades don't break things. You'd think
| it would be easier, but it isn't.
|
| I really wish React would just own the low level forms stuff
| and get rid of the need for a 3rd party form management
| library. That said, because it is frontend JS, there are 1000
| different ways to bike shed this problem and because it is form
| stuff, there is no one solution that fits all use cases.
| teetertater wrote:
| Which one? This sounds like it could be useful for me
| SCUSKU wrote:
| After some digging I believe it's this one:
| https://github.com/lookfirst/mui-rff
| mkl95 wrote:
| I once tried to learn what you would call "proper React", only
| for some Googler to tell me I wasn't even using React. Despite
| the fact I was using it back when hooks weren't a thing, and I
| had built multiple apps with it. There are many things I can
| stand in a community, but gatekeeping is not one of them.
| [deleted]
| ExtremisAndy wrote:
| I wanted to like React so bad. I tried. I loved JSX and really
| appreciated the way you could reuse components. That was all very
| cool, and I was initially quite enthusiastic about it. But for
| whatever reason, I just could not figure out state
| management/hooks. Drove me crazy. It just always felt so
| unnecessarily complicated compared to other languages and
| frameworks I've used (even vanilla JS). Now, don't get me wrong:
| I fully accept the blame here. I am mostly self-taught (and not
| even the best 'student' in that context, haha) so I'm sure I just
| lack the overall knowledge base/big-picture understanding to
| really appreciate what they've done here. I hope I'll give it
| another shot one day, and perhaps with fresh eyes (and maybe with
| the help of a patient tutor), it will all 'click'!
| caditinpiscinam wrote:
| I think there's a niche for libraries that allow you to update
| the DOM declaratively without any requirements on how you
| manage state. My understanding is that React looks at props /
| hooks in order to diff the state of your app and selectively
| recompute the virtual DOM. An alternative is to naively
| recompute the entire virtual DOM. I think this is how
| Mithril.js does it? It may be less efficient for large apps but
| it lets you manage state however you like.
| paulddraper wrote:
| Why did async/await replace callbacks? They are really the same
| thing, aren't they?
|
| Async/await allowed programmers to write _asynchronous_ code as
| if it were _synchronous_.
|
| Why did hooks replace classes/imperative? They are really the
| same thing, aren't they?
|
| Hooks allowed programmers to write _stateful_ code as if it
| were _stateless_. function MyComponent() {
| const [value, setValue] = useState(false); const
| clazz = value ? "on" : "off"; return <button
| className={clazz} onClick={() =>
| setValue(!value)} > {String(value)}
| </button> }
|
| This is functional code, without scary, hard-to-reason side-
| effects.
|
| Except for one limited part, which operates in a stateful way.
| preommr wrote:
| 1) React has no state management - approach it not from what it
| should be, but what it is - a tree of components that just
| render their props and where each component has some internal
| state.
|
| 2) Components have behavior. In Class based components they
| were implemented as methods. Simple enough, classes have
| methods. If you think about an iteration of rendering the ui
| tree, it goes down the tree and calls the mount method for each
| component in the ui. With hooks, instead of calling a method on
| an instance, it's implemented as an inner function of a
| component that is also a function instead of a class. Instead
| of explicitly calling the mount method on a class instance,
| calling a function that's a component automatically runs it's
| inner mount method. The way that it knows the which inner
| function is a lifecycle hook is because you import something
| like 'useEffect' from the react library. And that global
| useEffect function knows the current component because the
| renderer sets it as it's going down the ui tree. Hooks are
| better because they can be written as arrow functions (more
| concise, cleaner), and because you're calling a framework
| function, that function can have more complex behavior like how
| useEffect can track when to update because it's being passed in
| an instance of something like an internal state variable.
| fendy3002 wrote:
| Hooks are complicated, but state/props is just right. Both
| enables you to enforce boundary and make contained components.
| If props and state are mixed / diluted, the component won't
| know when to do re-render and there'll be too many things to
| track, and there'll be many classic issues such as cyclic
| dependency and sluggish performance of two-way data binding.
|
| Hopefully you'll click on it someday
| dqh wrote:
| I'd be interested to know if NakedJSX works for you. I released
| it about 6 hours ago. It allows you to use JSX to generate
| static HTML, and also in client JavaScript, but without any of
| the client side 'framework' stuff of React.
|
| https://nakedjsx.org/documentation/#getting-started
| skydhash wrote:
| Hooks use a different paradigm, which is a solution to a
| problem you encounter when doing functional programming, which
| is persistence and side effects. The whole of React is to build
| a tree of objects that will be rendered into a HTML page. The
| previous class-based architecture made it easy to store state
| and add side effects to this tree, by using properties and
| methods. But pure functional programming makes these awkward as
| functions are transient, only transforming parameters into
| return values.
|
| I don't know exactly how - never had the time to properly
| research it - but, my current guess is that the hooks code taps
| into the scheduler/dispatcher - which handles the execution of
| the function representing the component - and stores value and
| logic somewhere. It uses the order of these calls as keys - you
| don't have to specify them - and provides the stored values as
| return values of the call of the hooks functions.
|
| Hooks are escape hatches from the functional paradigm of
| React's components. You are always providing new values, and it
| decides when to store the updated version - mostly based on the
| deps array. You then get back what you stored. On the surface,
| it's still basically functional, but the actual logic is not.
| It's more like a repository of code and values.
| super256 wrote:
| I find the hooks so much easier to use than e.g. Google's
| ViewModel solution in Jetpack. They are just a joy to use.
| WorldMaker wrote:
| One view of Hooks is that they are monadic or at least Monad-
| like and the deps arrays are a crude (reversed) notation for
| algebraic side effects. ("Reversed" because they declare
| which dependencies have side effects more than they declare
| which side effects the hooks themselves produce.)
|
| It's still so very functional programming-inspired, even if
| the execution engine (scheduler/dispatcher) isn't that much
| like the Monad runtimes of most functional programming
| languages and the various Hook "monads" don't get captured in
| even the return type of functions (much less the parameter
| types) and get elided away. (It could be more "traditionally
| JS monadic" if it [ab]used async/await syntax and needed some
| fancy return type, even though the concepts for hooks don't
| involve Promises [or Futures, being the slightly more common
| FP Monad name]. Though also, from Typescript patch notes,
| I've heard React _is_ exploring [ab]using Promises for
| something like that in the near-ish future.)
|
| Monadic bindings needing to be in-order, just the like "Hook
| rules", isn't even that strange from an FP perspective: there
| can be a big difference in which of two Promises is awaited
| first. There can be a big difference in which IO binding
| executes first (you don't want to input something before the
| prompt of what to input is printed).
| [deleted]
| tomcar288 wrote:
| Don't blame yourself. Software engineering tools are supposed
| to serve the programmer, not the other way around. If a tool is
| too hard to use, then you're using the wrong tool. Tools should
| serve the developer. I would recommend plain old javascript
| with a light wrapper on top, like jquery. I know i'll get
| downvoted for this but a lot of "modern" javascript frameworks
| don't properly abstract the underlying layer properly (read
| Joel spolsky's article on leaky abstractions) and this results
| in a lot of problems. Furthermore, they optimize for the wrong
| thing: writing code. Most engineers spend 95% of their day
| reading code and that's a lot harder than writing code.
| qudat wrote:
| view = func(state).
|
| That's the magic of react. The problem is no longer manually
| managing transitions between state but state itself.
|
| That's why state management is so critical in the react
| ecosystem.
|
| Further, react has delegated two key features to userland: side
| effect and state management.
|
| Personally, I don't want react to solve either of these
| problems because it'll just turn into the disaster that is
| react server components: feature development driven by
| corporate interests (eg vercel).
| recursive wrote:
| > view = func(state).
|
| If this was actually how it worked, I'd have much less
| problem with react. What I mean, specifically, is that not
| all function dependencies are explicit. This makes it look
| like the state is passed into some function. And then the
| view is returned, depending only on state. In reality, half
| the state is passed in (as in the argument to a function
| call), and half comes out of some mysterious hook storage
| structure. If the state was really a function argument, you
| could easily inspect the whole state in a debugger. Instead
| of... I'm not sure how you'd actually do that.
| laurencerowe wrote:
| React Developer Tools makes it easy to inspect component
| state in your browser. https://react.dev/learn/react-
| developer-tools
| june_twenty wrote:
| I think that view = func(state) is an unnecessary complicated
| way to describe frontend development.
| qudat wrote:
| After years of react dev that is probably one of the
| wildest takes I've ever read. Kudos!
| switz wrote:
| > it'll just turn into the disaster that is react server
| components: feature development driven by corporate interests
| (eg vercel)
|
| if you've followed along with the react team's discussions on
| server components, it is very clear that vercel implemented
| _the react team 's_ vision and less so the other way around.
|
| as someone who has been using them extensively, I understand
| why. they're delightful.
|
| vercel does control next.js which is the only framework to
| completely implement RSC, but as other frameworks catch up,
| RSC will have a wider surface area.
| yamtaddle wrote:
| Hooks are half of an object/class system (implemented _on top
| of_ a language that already had a whole one--arguably, two,
| from a DX perspective, though they 're one under-the-hood) with
| non-standard and hard-to-read declaration syntax and bizarre
| behavior (FIFO-by-declaration-order property access and method
| invocation). It's not your fault you're having trouble with
| them, they're a weird boondoggle.
| boredumb wrote:
| React is really good for helping create giant SPA apps for the
| web. Unfortunately 99% of things using react aren't or shouldn't
| be SPA apps and now otherwise trivial applications are orders of
| magnitude more complex in their implementation and much heavier
| on bandwidth than necessary.
| TeffenEllis wrote:
| I think React really was revolutionary when your choices were
| jQuery, Backbone, or even Angular 1. I remember trying to
| convince my team that React was the next best thing when it first
| came out. Skepticism was everywhere -- especially around JSX. So
| we compromised and wrote our components with CoffeeScript...
|
| The sheer number of flux frameworks were a testament to how
| underserved the state model was at the time. And without
| consistent support for async/await to make Promises work well in
| an app, data fetching and state was the worst part of React.
|
| I've always despised Redux and the circus that came with thunk
| generators. MobX made things a little bit easier. And Baobab was
| a fun concept to bring Clojure-style cursors to JavaScript. It
| wasn't until React shipped the context API and hooks that I felt
| the problem of, "how do I get this state from up here to down
| there?" was truly solved.
|
| Personally, I've wished I could quit React for something like
| native Web components, but I feel like I'd be back at square one
| with state management and stringly-typed templates. Maybe Lit-
| HTML will get there one day!
| tambourine_man wrote:
| I was blown away when I learned the concept of the virtual DOM
| and how diffing it could be made fast.
|
| But as practical tool, React has been a regression for the web
| IMO.
| Kilenaitor wrote:
| How has it been a regression for the web?
| tambourine_man wrote:
| I don't think direct DOM manipulation was ever a problem, if
| done thoughtfully.
|
| If keeping track of state is so hard that requires a library
| to render it, perhaps you have too much state for a single
| view. It's ultimately a UI/UX design problem, as it will be
| hard on your users as well.
|
| I find the way they mix markup with code distasteful, and
| lots more.
| 5Qn8mNbc2FNCiVV wrote:
| It's less keeping track of state is hard and more keeping
| state in a medium that isn't suitable for it (the DOM). The
| argument of too much state in a single view is nil by what
| applications are built nowadays (and also expected).
| Obviously it was already possible without the rise of
| declarative rendering frameworks but it made it more
| accessible to the majority of developers and thus raising
| the bar.
|
| If you do however find the way markup and code is mixed
| feels distateful, I'd suggest to not look at any templating
| engine in the last 20 years because that's what most of
| them already did.
| yazaddaruvala wrote:
| > I don't think direct DOM manipulation was ever a problem,
| if done thoughtfully.
|
| Then you've never worked on a medium/large UI application
| (1k+ LOC), and most certainly couldn't have lived through
| the era of DOM manipulation!
|
| jQuery when it first arrived was a god-send! but even the
| most thoughtful couldn't structure it right.
|
| Backbone when it first arrived was a god-send! but even the
| most thoughtful couldn't structure it right.
|
| React when it first arrived was a god-send! but even the
| most thoughtful still can't always structure it right.
|
| With, the inclusion of so many other failed and semi-
| successful attempts throughout history I have no idea how
| you can possible claim:
|
| > I don't think direct DOM manipulation was ever a problem,
| if done thoughtfully.
|
| without just being naive...
| steve_adams_86 wrote:
| I don't agree with that blanket statement, though I do agree
| that it (and libraries/frameworks like it) have played a
| significant role in bloating the web. Perhaps even bloating
| development tooling in the JS ecosystem.
|
| At the same time, my capabilities with web applications have
| skyrocketed in the last ten years and I wouldn't credit it
| strictly to my experience. These tools aren't only used because
| they're relatively accessible; they're genuinely capable and
| powerful, and when used well, allow remarkably fast development
| and iteration on products with real value.
|
| I think that's better than the bad parts. Also, a lot of what's
| bad about the web today (for me at least) has virtually nothing
| to do with the tools we use to develop. It's that our attention
| has been commoditized, and that market has eroded a vast
| portion of what made the web exciting.
| nfRfqX5n wrote:
| big milestone for the team, congrats to all of the contributors!
___________________________________________________________________
(page generated 2023-05-30 23:01 UTC)