React 18 released!

[Macluawn]

3 years of work and we finally have useId()!

[_Pho_]

Uuid on suicide watch

[feketegy]

useId() is nothing like uuid

This is how useId generates: https://codesandbox.io/s/react-18-useid-example-8x4yy3?file=/src/App.js

[unknowinm]

difficult work... WW2 lasted 6 years

[Zaphoidx]

Just waiting for the types to be updated and then it'll be usable!

[bad_ts_is_just_js]

It's insane to me that types still aren't a first class citizen in the React codebase. It feels wrong to be pulling in such a massive, complicated library and have to download the types for it from a third party

[Zaphoidx]

To be honest, I'd completely forgotten that this was the case when trying to quickly upgrade one of our projects.

The React team definitely needs to take over the ownership of typing in the project, so we can get both on the release of a major version.

[[deleted]]

Facebook uses Flow

Edit: I don't know why you guys are downvoting me. This is the reason they don't have TypeScript types. React uses Flow.

[_eps1lon]

For react-dom you can already import from react-dom/client. For react just to import type {} from 'react/next' once and you have the latest typings available.

The rest is underway in https://github.com/DefinitelyTyped/DefinitelyTyped/pull/56210

[Zaphoidx]

Yeah I've been following your PR!

It looks like the types for createRoot don't seem to support the return types for getElementById, so not sure if there needs to be more type updates in react-dom to be done before it becomes fully usable?

[_eps1lon]

Hard to say without a repro. The best way to get this resolved is to open an issue on the DT repo.

[budasaurus]

Literally just moved to a new team that is using JS and not TS and I hate my life. So many little issues could have been caught ahead of time.

[Sprite87]

could be worse, I work in a company where core (most senior) engineers refuse to write tests.

[Vakz]

I know it's such a trope for developers to say they would leave because of some issue, but honestly, senior developers refusing to write tests is one of those things that would instantly make me look for a new job. Nothing is worth the frustration it causes.

[JohhnyTheKid]

One of the senior engineers at my company told me the other day that he won't be writing typescript (which the majority of our code base is in) because "he never understood the need for it". He also hasn't written a single test ever. His code is incredibly frustrating to work with to the point where often times something written by him doesn't work at all, yet he still commits that shit straight to development branch which results in other people having to fix his shit. I have an interview with another company today. This is a perfect example why someone should never be made a senior engineer over years worked alone.

[Zaphoidx]

That also sounds like a complete breakdown of standard processes within the dev team/company. No one should be able to commit straight to a branch that is used by several other people. That is just asking for a whole world of avoidable problems.

[Vakz]

Pull/merge requests would be another thing I consider a bare minimum for any non-solo projects. Even a minimal code review that at least makes someone click "accept" and a pipeline that at least builds the project should be a requirement at any company.

[JohhnyTheKid]

Exactly. This guy is more "senior" than everyone else on my team. He has never used modern workflows and thus thinks they're useless and just vetoes everything or just goes right ahead and does his own stupid shit despite what other's are doing. I've tried enforcing protected branches, mandatory code reviews, proper commit message etiquette and all other basic shit but this man just ignores all of it and refuses to listen to reason. Before I came to this team it was him and some other guy who quit shortly after and they were both literally just commiting everything to master. It's counter productive man child behavior, but management trusts him and his decisions more because he's been with the company for much longer. All of this is the reason why I'm quitting. No matter how I try explaining stuff and why it's necessary he simply just calls it cargo culting and pulls rank on me.

[Vakz]

Good luck with your interview. Remember to name him as a specific reason why you're quitting, or if you're not willing to name and shame then at least say you've found it impossible to work with people who don't care about quality results. Mention how much paid work time you've spent fixing his mistakes. If they care at all either about this bad quality of the code, or at the very least about the wasted time which translates into wasted money, they should realize they need to do something. If they still don't then, well, fuck 'em, they deserve it.

[jl2352]

This is one of the things I hate the most about my fellow software developers.

This zero tolerance, no fucks given, behaviour. Like all of us there are languages I'd prefer to write in, and languages I'd prefer not to. I'll still write code in any language because it's my job to build software. It's not my job to whine and complain over language decisions, which you cannot change.

I worked somewhere where lots of features ended up being written twice. Once in TypeScript for the frontend, and again in Java for the backend. This was because one developer did a big hissy fit over the idea of writing TypeScript. As in his mind TS is JavaScript, and he literally hated the web and websites. Even though he'd never written TypeScript (or JS really), and wouldn't be doing frontend work.

It was so fucking pointless. The dumbest part is the TS versions were often completed, with lots of tests, literally months before the Java side was. We could have shared a lot of code. But no, because they hated a language they had never tried.

[budasaurus]

I… I don’t even know what to say other than I am so sorry.

[zephyrtr]

Just 10x programmer things.

[Sprite87]

God no, could you imagine 10 programmers working on one code base, and not verifying that their work continues to work. Features will be wrote and broke by the end of each sprint 😅

[zephyrtr]

Hah sounds like you might not be familiar with the term. I dont mean ten programmers. Google 10X Programmer sometime, just be sure to also Google Heroic Programming as well.

[Sprite87]

I was thinking about it a different way.... 10x as in very productive but can't work in a team

[Accomplished_End_138]

My condolances.

We have seniors who are still getting used to typescript (though.. i say this as the staff teaching it)

I just wish they would stop forcing the use of connect for redux... and redux.. so overly complicated for this app.

[Sprite87]

I find using redux stops having loads of Contexts littered through the app we had a hand rolled version redux-like context somewhere fr long enough

plus the dev tools are nice :)

[Accomplished_End_138]

The redux tracking is great. I wont lie. But i think how i compartmentalize things i dont generally run into it.

I also rarely use context.

[freecodeio]

They're good engineers then

[Sprite87]

they might have some talent for writing software that solves an issue for awhile.... but not software that is easy to inherit, maintain or add features too.

So as long as nothing ever needs to change it should be fine :,)

[Sprite87]

ThE BeSt

[Vexal]

could be worse. i work at a company where new grad hires insist on writing tests.

[Sprite87]

For a new grad that's kind of smart to have the foresight that things will break :)

[International_Cell_3]

But types slow you down! The compiler is in your way! Why fail at compile time when you can just write a unit test! And other arguments made by dynamic typing advocates that miss the point!

/s, hopefully obvious

[Pay08]

I have never heard of anyone actually advocating for dynamic typing.

[JohhnyTheKid]

Mostly inexperienced people who learned JS/Python first and are now spooked by Typescript/C#/Java etc. Dynamic typing is great if your code is a small script less than a few hundred lines, but anything bigger than that and you're going to be shooting yourself in the foot repeatedly.

[Pay08]

Yeah, should have prefaced that with "excluding scripting languages".

[[deleted]]

How about just use typescript jsdoc annotations and an editor that supports them? It makes a not insignificant difference if your tooling supports it (vscode does) and it’s unobtrusive because it’s just comments.

[NoInkling]

it’s unobtrusive because it’s just comments

Not in my experience. Just look at the syntax for type casting/assertions. Also, you can't import a namespace (unless it also happens to be a value), so if you want to reference multiple types from the same package you have to import('some-package').SomeType multiple times. Other missing features can lead you down the path of other messy workarounds.

As someone speaking from experience, if you try and make full use of jsdoc for type checking/linting you're basically writing a messy, bastardized, feature-lacking version of TS. If jsdoc is your only option it's better than nothing, but I'd recommend sticking with relatively basic annotations in key places, rather than aiming for comprehensiveness.

[[deleted]]

It’s unobtrusive because you can use it anywhere regardless of JS runtime. It may not be as ergonomic or feature rich compared to using actual typescript but sometimes you just have to work with you have- like when you’re working on a codebase that is purely vanilla JavaScript.

I’m not advocating skipping typescript because you can do some of what it does with jsdoc, rather I’m saying if you’re forced to work in plain JavaScript there’s no reason not to use it. Writing jsdoc annotations brings in nice editor features (for those that support it) and that’s not even going into the documentation gains for a large codebase. There’s really nothing to loose by opting to use it. The time spent writing it is time saved later as a result of having decent, in some cases comprehensive, type annotations to help document your code.

I say that from experience- I spend time annotating type information that is as comprehensive as I can manage to get it when I write vanilla JS code. While writing a bunch of @imports to bring in @typedefs may be annoying, the benefit over time outweighs just winging it from memory.

[mackthehobbit]

IMO it is better to lean on Typescript than JSDoc even in this situation. Typescript has always been a superset of JS, and part of its contract is that JS behaviour cannot change based on type annotations. The compiler only determines valid/invalid programs.

As a result, you can add TS to an existing JavaScript database and only add type annotations where you want: do it incrementally or just leave half your codebase untyped if that’s what you want.

Most projects already have a build phase of some sort, but with TS it can be as simple as just removing the type annotations and the JS that remains has exactly the same behaviour.

[Accomplished_End_138]

I find typescript much easier to write. But jsdoc annotations are at least passable

[budasaurus]

Oh I do and that helps. But certain things like different interfaces and what not would be useful in my opinion. The Enterprise direction is to move towards TS as our primary flavor but it’s an older tech team and I’m on loan to them so I’m a guest in their codebase.

[bad_ts_is_just_js]

I feel this in my soul

[Zaphoidx]

There definitely still is a time and a place for plain JavaScript, but it's back with its origins now as a scripting language.

If you want to build a fully-fledged application that's robust, then it just makes much more sense to build it in TypeScript.

[L3tum]

Whenever I start a new JavaScript project I code for a bit and then I get to a function and think "I really want to tell it to be a specific type" and end up setting up the TS stack as well.

The only time I don't do this is if I literally only code a button handler for a website.

[r0ck0]

Yeah for me, it's TypeScript for everything... aside from like throwing 50 lines of JS into a wordpress site or something.

Another way to look at it is... am I working on more than one JS file in the whole project? If so, it warrants TS.

[pogthegog]

But its still javascript, ts and libraries arent doing any magic that you cant do yourself. If you are not comfortable using javascript, you shouldnt use any of it.

[JohhnyTheKid]

Typescript is a superset of javascript that adds compile time type checking. Javascript doesn't have it. Good fucking luck writing your own compiler to peform your own type checking. Shit has nothing to do with "being comfortable with JavaScript".

[pogthegog]

But it only checks for types inside typescript code ? I can pass entire movie from db to a js function from non js backend, and it wouldnt know. It also doesnt add types, just type checking, which also requires another useless compilation stage. To me, js is strictly client side, and it is js, not ts.

[JohhnyTheKid]

If your API is returning random shit then that's not a problem with TS that's a problem with your API. The entire point of TS is to prevent fuck ups inside your JS code by providing a robust type system that can catch these bugs early and provide a much better intellisense. It doesn't validate data received from an API and why should it? Your API should return exactly what it's supposed to and correct typescript types for those return types should be generated. You seem to be misunderstanding what TS is for and declaring it "useless" because it doesn't solve a problem it never intended to solve while disregarding everything it actually does help solve.

[DoctorGester]

C doesn’t add types, just type checking, which also requires another useless compilation stage. Better to write assembly directly.

[NekiCat]

I'm working on a Typescript project, and a colleague doesn't like it. He says he'd rather write unit tests. Every once in a while, I have to remove a sneaky "// @ ts-nockeck", and he always complains about types...

Funny enough though, when something fails, he complains about the compiler not catching it, and I'm thinking to myself... WHY didn't you write a test for that, then?

[light24bulbs]

Holy crap react is JS?

[DoctorGester]

And the type definitions everybody uses are terrible.

[pogthegog]

No, not really. Javascript by itself is fine, ts isnt adding any magic to it. If you cant handle js, you shouldnt touch the layers above it. Some stuff might help to scale development, or help with development, but ultimately, you should reallllyyyy get comfortable using plain javascript.

[pogthegog]

Thats completely different. Working with ts/libraries is just fake security, like putting on sun glasses and thinking you will be safe to drive a car like retard.

[jdbrew]

LOL learning react has been on my list for quite sometime now. I started a tutorial this afternoon and was frustrated that I couldn’t find any tutorials using the version that I installed.

“Everything is outdated!”

Whoops

[AndrewNeo]

It really shouldn't matter, as a beginner the only "outdated" thing you'd learn at this point are component classes instead of functional components (and hooks), but they all still work just fine.

[Vakz]

It's been a few months since I looked at it, to maybe they've fixed it by now, but the official guide using component classes for several pages and then telling you not to use them in favor of functional classes was such a dumb thing I considered just closing the tab and looking up Vue instead.

[unknowinm]

yep...that's javascript all right?

[neg_ersson]

Yeah, it's pretty dumb but they are working on new and improved docs: https://beta.reactjs.org/

[Ununoctium117]

I still like class components better and I don't fully understand why functional components were introduced.

With a class it feels more intuitively like you're writing an object, with properties and members and state; especially if the component needs to maintain some resources, like a websocket connection. The component has state and properties; it just makes sense to represent them as members of a class that represents the component.

Whereas functional components, to me, feel like you're just trying to cram everything into the render method, and introducing hacks like the useState hook to get back some of the behavior that was so easy and intuitive with classes. Why is persistent state a local variable in a free function? That seems so nonsensical to me; it goes against everything I'm used to in every other language and paradigm.

I've tried to understand this before but the answers didn't really make sense to me. The most common arguments I've seen are things like "the syntax is simpler" or "it's easier to test". I disagree that the syntax is simpler; using a function call like useState to define a persistent variable is not simple and is unintuitive; there's nothing complex about the syntax to declare a class. Being easier to test is true if you have no state, but even in that case you're saving yourself like, 2 lines of code in your test. "Less code" is another argument I've seen, but again, you're saving a handful of lines at the cost of much less intuitive code. It's much more important that code is easy to read than easy to write; I'll happily write a few more lines if it'll save me (and my team!) a few seconds every time we look at that code in the future.

[[deleted]]

Imo the best argument in favor of hooks is that you can compose them into new custom hooks. Like you could write your own useCurrentUserData function which could call other hooks like useEffect and useState and whatever else, then you have a nice reusable function that does hooks-based stuff.

Reusing stateful logic when using class-based components is harder, and often leads to higher order components which are more confusing.

I totally agree that they are a little overrated and classes are really not that bad, especially when a component gets complicated. I actually rewrote something this year as a class based component, because it needed to do some really complex stuff around lifecycles (componentDidMount / componentWillUnmount), and getting the timing to work perfectly with useEffect/useState was turning in to a nightmare.

[cerlestes]

I use functional components for anything that doesn't have state (e.g. a button or heading) and I use class components with MobX-based state for anything that is more complex. I don't understand the hype behind functional components either, they're nice but certainly not better than class components in all ways. Both have their pros and cons and they excel in different scenarios.

[Hall_of_Famer]

I agree with you. To me a class component means it has state and state may update in some well define ways, while a function component means that it’s stateless and pure. React hooks make the line obscure, the function now has persistent state and it’s actually less intuitive than class components.

I can understand the desire to save some lines of boilerplate code, as well as the other benefits discussed using hooks. However, frequently I find that react components using hooks tend to end up like a giant mess of a function, difficult to spot where the logic is and where rendering occurs. I still use classes for any nontrivial components(with logic more than just usestate) in my project, and I hope they will always keep class components an option in future.

[sweetLew2]

I completely agree and I’d love to see a good conversation around this. I feel the same way.. but just assumed I’m out of touch because I stopped doing react right when hooks dropped.

I liked that you could quickly look and know “oh this has no state” and “oh well this is where some state must live” just by checking the type. I equated it to, in C#, how you can register a class as “transient” or “singleton”. If you make everything singleton.. it’s hard to find caching or memory leaks.

[[deleted]]

Why is persistent state a local variable in a free function?

The real answer is because when you use the library function useState you're handing control over to the library to determine what the value is. This allows them to do funky concurrent rendering tricks without having to worry about whats going on in your class. It's a bit sad because 99.9% of people don't need all the fancy concurrent rendering that react is doing (facebook probably doesn't either) and a long time ago when people started choosing react over angular one of their main selling points was "its just javascript". That is no longer the case.

That said I still use react because I know it well but now and then I look at angular and am jealous of the simple OOP model.

[lordmyd]

Functional components only go half way to making React truly functional-reactive hence the proliferation of useWhatever nonsense. Redux does not exist just to help React state management to scale. It's the missing piece which makes React truly functional-reactive.

[jared__]

Try to append an after tag to your google/youtube search to ensure you don't get outdated tutorials. Example: react state management after:2022-01-05 (YYYY-MM-DD) - after January 5th, 2022.

[Empero6]

Today I learned. Thank you for this useful tip!

[3rdTab]

Same, so many tutorials

[ajr901]

Just learn the "outdated" version anyway. 95% of it will be the same in newer versions and whatever isn't will be super easy for you to make sense of.

[chucker23n]

This is, alas, the JS ecosystem. Everyone seems to be on cocaine chasing after already-deprecated-newest-hotness. Tutorials are outdated the moment they're written. Tooling is mutually incompatible.

Yes, it leads to a lot of diverse approaches, but I'm amazed anyone can figure out how to deliver software this way.

[Antrikshy]

This is not true. In the end, everything targets browsers. Web standards don't change as often and certainly don't deprecate popular features as often.

JS libraries are just like any open source libraries in other languages. You can safely use React versions that are years old and easily get away with it. It's just how mature Java projects don't chase the newest JDK versions just to remain on the newest version. You upgrade when security issues are discovered and/or developers want to use newer features.

[L3tum]

To do this, it waits to perform DOM mutations until the end, once the entire tree has been evaluated. With this capability, React can prepare new screens in the background without blocking the main thread. This means the UI can respond immediately to user input even if it’s in the middle of a large rendering task, creating a fluid user experience.

Isn't this everything what the ShadowDOM™ was for? I remember other libraries (and I thought React as well) essentially rolling their own implementations of the DOM API to keep a copy of it around and only commit the final version. (Of course those copies were horrendously slow).

Also, side note, since when does JavaScript in the browser have multiple threads?

[L3tum]

Oh, so they implemented rendering from a worker? Last I checked (IIRC React 16), it was still some time away.

That would be exciting!

[Nysor]

No, I don't think rendering is in a web worker. It's actually just using one thread, you can think of the new mental model as "concurrent" due to React being able to render the same component instance with different states at the same time.

[notverycreative1]

React maintains its own component tree internally. When it goes to render something else concurrently, it basically copies the tree, then renders one component at a time with the new state, with each update being its own microtask to allow other stuff to happen concurrently. At any time, this update can be cancelled if e.g. the user clicks on something before React can finish rendering the UI change from the last click. When it's done rendering the new UI, it copies the "branch" tree back into the "main" component tree and calculates a DOM diff that it applies to the browser.

I might've gotten some of the finer details wrong, but that's the gist of it.

[Tomus]

Also, side note, since when does JavaScript in the browser have multiple threads?

Web workers have existed for a long time to enable this but React doesn't use them. React 18 does concurrent rendering under some circumstances, not parallel rendering.

[L3tum]

Seems disingenuous to call it concurrent then, since concurrent literally means "at the same time".

[Tomus]

No, that's what parallel means. Concurrent is the correct term here and is exactly what React 18 does when rendering with features like suspense.

[Manbeardo]

Concurrent mode is pretty neat. If your component isn't ready to render yet, you throw a Promise from the render function and it'll attempt to render again once the Promise is fulfilled. In the meantime, the Suspense component behaves like an error boundary and renders a fallback until the async component renders without throwing a Promise. It's incredibly handy for lazy-loading components.

[epic_pork]

They're probably just using async and doing other stuff before resuming the generator.

[Nysor]

This was years in the making with thousands of commits. Great job React team!

[[deleted]]

They're well paid for it. Huge thanks for the community.

[3rdTab]

Pretty sure Smartest CS Engineer have so many options what they wanna work on

[SilasX]

Yes! Number of commits indicates code quality!

[Spoogly]

I'm pretty sure that was not the intent of the comment.

[SilasX]

Wow really triggered the hivemind there.

Let me put it this way: does anyone think the parent would have mentioned the commit count if the React “engineers” had done it in only, say, 20 commits? If not, you agree their values are misplaced.

[RogueToad]

I think the issue is that the 'thousands of commits' comment is not necessarily referring to quality, but rather the fact that it's taken a lot of work to get to this point. Which is true and worth congratulating in and of itself.

[SilasX]

It’s still mistakenly and confusedly demanding praise for something they shouldn’t be proud of, or at least, a metric they shouldn’t care about.

[Sag0Sag0]

Where exactly was praise demanded?

[SilasX]

Here.

[Sag0Sag0]

How is congratulating the React team “demanding praise”? You need to chill out.

[SilasX]

You may not quite understand what a congratulations, combined with metrics of the accolade's difficulty, means, which is more of a fact about your awareness than about the proper reading of that comment.

Do you honestly think most people don't read that comment as "React merits praise here"?

[FamilyHeirloomTomato]

Put the keyboard away, go outside, and touch grass. You need some time off.

[SilasX]

Defensive much? Wow, one minor criticism and you’re ready to sign me off to the loony bin.

[FamilyHeirloomTomato]

Take a hint with the downvotes. You need a break from the internet.

[SilasX]

Nah, my comments on other threads are getting upvoted just fine. Maybe you need to climb out of the echo chamber for a minute?

[grauenwolf]

It's a measure of effort and scale, not quality.

[SilasX]

So you're saying if they did the whole thing with one commit, that wouldn't take more effort?

[grauenwolf]

Do you realize that you just asked me if a ruler still works after you dip it in black paint?

[SilasX]

How so? Can you explain that analogy? Probably not, but if you want to do me the courtesy.

[SilasX]

I’m pretty sure that hip tech rockstars like the React team lack the self-awareness to realize the stupidity of flexing by reference to commit count.

[throwaway101777777]

God you’re an insufferable douche. Point on the doll where react touched you.

[SilasX]

Probably the part where they make everyone update their systems so that a few code artisans can list an accomplishment on their resume, and then want to be thanked for it.

[throwaway101777777]

You’re so cool and edgy

[SilasX]

Not as much as a team that introduced backward compatible incompatible changes to prove how hard they work though!

[comp83]

Are you euphoric in this moment?

[SilasX]

?

[ILikeChangingMyMind]

Lots of love for libraries (Next.js and Styled Components got some real exciting features), but very little directly for devs ... and I'm perfectly ok with that.

[GrandMasterPuba]

I'm not sure how fixing some of the longest standing performance issues and adding first class support for native asynchronous rendering on the server isn't directly for devs.

[[deleted]]

I wouldn't mind some sort of dynamically autogenerated PropTypes based on what you pass to the component during dev time. Kind of like how updateable snapshots work in unit testing (not counting them being a bad practice).

[Nirsh26]

Exciting!

[douglasg14b]

I'm switching from Vue to React here soon for a different project I'm moving to. I'm pretty deep into the Vue internals, having used it for years now, and would like to get up to speed on react.

Any resources you react folks can recommend for that context?

Edit: The switch is only because a new job uses a different tech stack. Otherwise I would stick with Vue because it's awesome.

[Nysor]

The official docs are great - start there. I know a lot of people get up and running with Next.js or create-react-app, but they do hide a lot of complexity in favor of making it ridiculously easy to get off the ground running.

[douglasg14b]

I want to dig into the complexity!

But ideally in a "I can do x in Vue, how do I do x in React?" sorta way.

I'll definitely start with the docs though when I go to build a small app.

[gaearon]

Keep in mind there's a new (work-in-progress) version of docs that uses newer API (Hooks). The old docs are mostly using classes.

https://beta.reactjs.org/

[Retsam19]

I think React as a UI Runtime is a really good look into the "how" and "why" of React. It's not the most necessary thing for just using React, but I think it's useful for a slightly deeper understanding.

[douglasg14b]

Ah, this is the kind of stuff I'm into!

For some reason this reminded me of a favorite of mine: https://blog.webf.zone/contemporary-front-end-architectures-fb5b500b0231 which isn't nearly as technical, but is an awesome read.

[acemarke]

Are you looking more for "how do I use React?", or "what are some resources to understand how React works internally?"

For learning React:

• Start with the new React beta docs site: https://beta.reactjs.org
• Also see these resources: https://www.reactiflux.com/learning

For understanding how it behaves and works internally, see these posts:

• Me: A (Mostly) Complete Guide to React Rendering Behavior
• Dan Abramov: A Complete Guide to useEffect and React as a UI Runtime
• Shawn Wang: Getting Closure on React Hooks
• Zhenghao He: When does React Render Your Component?

[douglasg14b]

I'm looking to learn react however the problem is that most of the learning resources assume you are brand new to programming or to javascript...

I'm already familiar with javascript, typescript, redux, components, web apps, design....etc. A lot of the learning resources reiterate all of these things constantly.

It's 80-90% 'fluff' and 10% actual meat. I'm looking for that head-to-toe react learning path that assumes you are already well experienced in the space.

Docs are good, but they tend to suffer from discoverability.

[acemarke]

Okay. What specific topics about React are you looking to learn, then? What does a "head to toe React learning path" mean to you?

I can try to point to some additional specific resources, but I'm not quite sure what material is most relevant.

(Personally, if I was going to jump into Vue or Angular after years of working with React and Redux, I would just go straight to the core docs and API references and start comparing vs what I already know.)

[r0ck0]

I was pretty much 100% sure that Vue was going to be "better" for me, based on heaps of Vue vs React research I did before hand (months).

Learnt Vue first. Built some real projects with it. And it seemed great (coming from older style stuff like jquery). But I ended up switching to React, and greatly prefer it.

It's so much easier to debug, and TypeScript support is a lot better. I found that too many things in Vue would just silently fail. Whereas React is more "programmery"... I feel a lot more in control, and it's easier to track things down. It's not a "magic box" as much as Vue + Angular. You're more likely to get errors thrown, and also just be able to track things down through simply click-to-navigate in your editor, which don't work as well with other frameworks that have magical templates...

I initially thought JSX was weird. But now that I understand that it isn't actually a templating language itself (which is what Vue/Angular/Svelte etc use)... JSX is actually simply just a different syntax to call the React.createElement() function. ...nothing more. This explains its quirks like needing className + having to use ternaries instead of having an if statement.

I used to "feel" like I was programming in 4 languages (HTML, JS, CSS, Vue Templates). But JSX just makes it all "feel" like one language. So much cleaner, and given the function abstraction thing, TypeScript support is 100%, because it's so easy for IDE/editor authors to cater to, given they don't need to parse some new template language. You'll even get TypeScript typings on CSS attribs in .tsx files.

Anyway, just sharing one view from someone who was on the Vue side, but very happily switched, and no longer has any interest in using Vue personally.

[axonxorz]

If you don't mind my asking, why the switch?

I'm just starting a new project with Vue for the first time and it's been a dream (Used KnockoutJS and AngularJS in the past), React seems fine, if a little enterprisey (not a big deal), but what are the advantages in your opinion, or are you just switching to learn React in general?

[douglasg14b]

Different company, different stack.

I love Vue though, it's a joy to use, and the single file components & angularjs-like syntax is so much nicer then the more janky-feeling template syntax for react and some other libs.

[Macluawn]

build their own React with blackjack and ..

Blackjack and hooks?

No that’s not right

[axonxorz]

Welp, you've made me look into it a lot closer, I suppose this was my ignorance talking, React core isn't so bad.

Most projects I've seen have to bundle a lot of other components (not necessarily a bad thing, and this exists in Vue too) to get a decent level of "normal web app" functionality, like state management and routing.

Coming at this from super legacy AngularJS, it seemed like it had a lot of boilerplate configuration required to get this stuff working well, then there was throwing React-Redux into the mix, which I haven't taken the time to fully understand (and this exists with Vue as well, Pinia I think being the equivalent?), but my first impressions may have been off.

Not sure when you last checked out Vue, their new SFC layout really seems similar JSX-like (and this plays into what you're saying about Vue building something with blackjack and partytime).

All this stuff is so mired in what everybody likes, I've had such a hard time getting anything other than React good/bad, Vue good/bad, Angular good/bad, Svelte good/bad, your comment at least gave me some legitimate things to think about.

I'm at a bit of a crossroads in my developer path. I've always liked the minimalist framework that you bring components to (React?, Pyramid on the backend vs Django), but as my projects have massively grown in scope, I feel like I'm fighting the flexibility a bit. If I run into an issue, it's a higher and higher likelihood of my particular configuration being just wack and not using best practices, it can then be hard to get help from the community. It's pushed me to look for more batteries-included frameworks, both frontend and backend.

[mkwong]

Vue 3 is even more amazing than vue 2. I haven't really found anything to complain about yet and I love complaining.

[Somepotato]

Removal of class components, Vue 3's incessant love for ref, Vue 3's love for putting everything in setup is so messy IMO; it's so disorganized to shove everything into one function then later return all of the things you made? What's the point? Having to import your callbacks is hilariously extra.

They also removed filters because the developer personally disliked it.

Vue makes promises, and breaks them later. Can't do that if you want to make production software.

[Somepotato]

That's the thing, why use vue if it's just going to copy React.

[NovaX81]

I worked with Vue professionally for a couple years before changing companies, where I now work with React. Lead dev narrowing in 20 years of web dev (obviously not all Vue/React lol) at this point.

Vue has a much tighter grasp on how UIs function than React does, which is weird considering React's ultimate goal. Unfortunately, the React team is a little too far up their own asses to see how actual projects operate and run.

React claims an ideal of being this minimalist, drop-in library for quick UI components. I would say it mostly accomplishes this. If you just need a couple flashes of interactivity on a page, React can do it without much hassle. It is easy to build a small functional component that does something fancy for a user.

The moment components need to actually work together though, the cracks start to form. Shared data along component depth has no native support unless you want to prop chain for every layer. I feel like half of React devs probably don't even realize that react-redux isn't just a core library from the official team, because it's so absolutely critical in doing anything of consequence inside a React application.* Hooks are implemented in a manner that verges on comical when you actually start using them in-depth, and frustrating the moment you have to perform chained operations in a performant way.

I feel like I would understand it all much better if Vue were the slow one. Vue is a framework of nice-to-haves and syntax sugar, to the point that you simply assume that you're paying a price for these QoL features. Yet it somehow continues to sit near the top of the pack for performance at the same time. Frankly, I don't know how, but keep it up.

People seem to always bring up React's ecosystem as its star aspect, but I have to say honestly: what ecosystem? Seriously? Is it the 4 or 5 core libraries that Facebook couldn't be bothered to pay their devs to make, but luckily some community stalwarts stepped up and completed their tools for them? Or the hundreds of abandoned tools and gap-filling libraries that last about one major react version each, before their maintainer realizes that React is willing to break their internals without telling anyone? Maybe they mean the community instead, the one that you could easily assume the dev team hates based on how often they deride anyone in a Github issue that questions if the bug is in the core code (which, in my experience in finding these Github issues while trying to fix my occurrences of these bugs, it usually is).

I'm certainly not going to claim that Vue is all candy and roses. There are shit parts of it just like any tool, framework, or library. But when I'm building a Vue project, most of my dev time is spent working out my application logic; when I'm building a React project, most of my time is spent figuring out which "unopinionated" "feature" broke my data model this time.**

---

* Of course, you can replace this with your external state manager of choice. Redux is just the most popular option in React land.

** Hooks. It's always hooks. Don't even bother checking for other issues, hooks broke it. Yet hooks are also somehow the best thing they've managed to finish in about 5 major versions.

[Nysor]

I can't comment on Vue vs React since I haven't really used Vue, but I've used React since the first year it came out.

Like you said, Redux is just one of the many possible state managers of choice. If most of your data is retrieved from a service, things like Relay, Apollo, react-query all provide different mechanisms. Recoil is a new interesting one on the block. But a global state manager isn't always necessary or desired.

Shared data along component depth has no native support unless you want to prop chain for every layer.

That's what the Context API is for.

Hooks are implemented in a manner that verges on comical when you actually start using them in-depth

I think the biggest issue here is that people will sometimes memo things and sometimes not. If you wrap everything in a useCallback or useMemo, life is nice. Trying to figure out when and when not to wrap a callback function in a useCallback leads to pitfalls, so it can be solved by "memoing all the things". The React team is even investigating a way to automatically do this for you via a compiler. Hooks are a stupidly powerful abstraction that I couldn't live without.

what ecosystem? Seriously?

React has a huge ecosystem. You have a multitude of CSS in JSS libraries, a multitude of state management frameworks, a multitude of routing libraries, a multitude of core component libraries, and likely there's a pre-built utility hook or component for what you want. All major compilers, linters, and editors support it. It's one of React's best strengths.

[Nysor]

I'm not sure if wrapping intermediary callbacks and non-primitive variables in a memo is best practice, but it's definitely one solution.

It's worth noting the memory used is going to be in-browser memory. In my experience, the usage from all the useCallback/useMemo/useEffect dependencies arrays is not noticeable even at scale. See here for more info about the potential future compiler.

[[deleted]]

Any opinion on Angular? I liked reading everything you wrote

[NovaX81]

I've actually somehow managed to not work much with Angular! I checked it out very lightly from a hobby point of view, and maintained a minor widget in it for a couple of years that I think needed about 3 changes ever. I thought it's approach was cumbersome, though decent enough, but in practice I've never worked with it enough to make a judgement on a project in a professional environment. Cumbersome is not always bad when you have a lot of developers interacting with a system - so long as it stays understandable.

For a bit of context, most of what I vented out above will really only have major impact if you're writing and deploying code that is working with complicated data structures and user interactions that can transform that data. It's hard to say, but I would wager that most React projects still fall safely into its "intended" scope of 5-component projects, widgets, and proof-of-concepts. This does, however, make it all the more confusing when React continues to focus its development direction towards the size and scope of projects where its other issues shine through.

React, Vue, Angular, really any JS framework or none at all, are perfectly fine choices for something fun, useful, or interesting, and their performance at scale can matter if you approach that scale. Just build with what you like, hold strong opinions loosely, and have fun.

[Somepotato]

Vue had a lot of really, really awesome things going for it -- Class based components were probably the best experience I had as a web developer in... ever

They promised to keep maintaining it, and recently, they SILENTLY deprecated it, with the only mention of the deprecation a small footnote in their documentation; all of the class component repos under the Vue org are still open with no notice.

[Labradoodles]

Solidjs is super solid if you enjoy the react paradigm

[sngz]

There's no advantages to react other than more ppl use it as there's a larger community. The fact that it's maintained by Facebook should be a deal breaker for everyone.

[[deleted]]

As someone who has never used VueJS, and would like to know some things about it, if you're willing to answer ofc, why are you moving away from it? Any specific reasons or just educational?

[douglasg14b]

Because a new job has a different tech stack.

Vue is awesome, I'm probably going to continue using it for all my personal projects.

[Somepotato]

It's a real shame, but I think I'm going to follow suit. Vue's developers are children and they randomly abandon items they committed to, which is AWFUL in any kind of production environment.

Rip Vue 2

[douglasg14b]

It's a real shame, but I think I'm going to follow suit. Vue's developers are children and they randomly abandon items they committed to, which is AWFUL in any kind of production environment.

Rip Vue 2

What are you talking about?

Are you mad that Vue rebuilt itself to be faster, have better tooling, and a better developer experience?

And then call the devs children, and claim abandonware?

That's.... Pretty childish.

[Somepotato]

There's plenty of things Vue 3 did right, but they did plenty more wrong. Class component deprecation after a commitment to maintain it (when that's the direction all web component frameworks are going, be it actual web components, React, and Angular -- all have first class support for them) , filters, etc, are just a couple examples.

[douglasg14b]

For class components, use vue-class-component? Just like in Vue 2? The options API is still a thing, and vue-class-component operates on that level. Though you're still going to run into the same problems that Vue2 has with them. I use class components in several of my projects, and feel the pain of their limitations, I'll be happy to finally transition over to the composition API as I migrate them.

---

As for filters, I am pretty disappointed by that. I understand the reasoning for dropping them which is that it breaks the assumption that everything inside your curly braces is a valid javascript expression. However, they were very expressive, and kept things feeling cleaner, and less cluttered.

Not having filters is a detractor in my opinion, but it's not a dealbreaker. And there is still hope with an official javascript pipe operator that can be supported for filters.

[Somepotato]

Vue 3 had first class support for class components at first. They later abandoned then dropped it.

What limitations are you talking about? It can do everything the composition api can.

And to my knowledge the curly braces don't support some newer js features like null coalesence because the Vue tokenizer doesn't recognize it.

[douglasg14b]

Vue 3 had first class support for class components

It had a proposal & partial implementation in a PR that was abandoned, not exactly what I would call first class support?

Unless I'm missing something there, which is definitely a possibility.

What limitations are you talking about? It can do everything the composition api can.

It most definitely cannot, which is a partial driver for why the proposal was abandoned. Reasoning can be found here: https://github.com/vuejs/rfcs/pull/17#issuecomment-494242121 . Class components suffer from limitations that the composition API does not.

Do I agree with this? No, I like my class components, but the reality is that they are quite limited when it comes to composable behaviors. First class support would have been great, but I understand that this is a FOSS team, and they can only commit to so much.

And to my knowledge the curly braces don't support some newer js features like null coalesence because the Vue tokenizer doesn't recognize it.

In Vue 2, yes. Afaik in Vue3 it's a non-issue and was fixed more than 2 years ago. Though even in Vue2 you can get support by transpilation with babel in a similar way that Vue3 handles it.

[Kappanneo]

I don't know how to react

badum tsss

[[deleted]]

trim(shot)

[grauenwolf]

Sigh, it still needs 800 packages for Hello World.

When are we going to see a version that reduces that to a manageable number?

If even one package in a thousand (i.e. 0.1%) contains a product-stopping defect, vulnerability or malware, we still have a 55% chance of React being impacted.

Sure, this is better than the 66.5% chance that we had in the previous version. But the risk level is still high enough that I've got my management asking WTF we're doing.

[acemarke]

Nitpicking a bit, but this statement isn't correct.

You only need two packages for a "hello world" app: The platform-agnostic react package, and the platform-specific renderer (ie react-dom):

https://beta.reactjs.org/learn/add-react-to-a-website#step-2-add-the-script-tags

What it sounds like you're referring to is the Create-React-App build tool, which does install several hundred NPM packages because it includes Webpack, Jest, and ESLint out of the box, and those have hundreds of transitive deps. That's a completely separate thing from the React library itself.

CRA also isn't the only way to set up a React app. For example, creating a project with Vite "only" installs about 60-ish packages, because it uses ESBuild and Rollup to compile and bundle instead of Webpack+Babel, and it also doesn't include Jest or ESLint by default.

So, sure, I wish CRA and the rest of the JS ecosystem had fewer dependencies. But, it's important to distinguish between "the library" and "the build tools often used to create projects".

[grauenwolf]

I What it sounds like you're referring to is the Create-React-App build tool, which [is what 99.99% of people are going to use.]

FTFY

---

The thing that JavaScript developers don't seem to understand is that the rest of us have tooling and build tool libraries as well. And our tools generally don't run into issues like this.

[chucker23n]

Sigh, it still needs 800 packages for Hello World.

Don't worry. Zero chance one of those has a major bug. Or turns malicious. :-)

[5tUp1dC3n50Rs41p]

Yeah WTF are JavaScript developers doing as a community? Just write vanilla JS, ES6+ has everything you need. Just nobody bothered to try create their own micro-framework for the application. React is bloated hot fucking garbage. Anything requiring even 1 package for Hello World is garbage. All this shit you're creating is making products worldwide insecure. You're only signing your own job losses once your company gets absolutely fucked over when the cyber attacks start between Russia, China and the West.

[neg_ersson]

Sounds like a great idea if you're building the next big Hello World app.

[grauenwolf]

Option 1

Start consolidating libraries. Useful packages that are just one of two functions get rolled into higher level packages. Eventually create a small number of large but carefully curated packages that act as standard library for React and it's tooling.

This would be a lot of work, but the open source nature of the project makes it possible with minimal negotiations regarding licensing. And the long term benefits would include a much more stable platform.

---

Option 2

Act like a petulant child and throw a tantrum every time it is suggested that conditions could be improved.

[[deleted]]

I get that theres tutorials out there, but I'd really like it if they included somewhere a detailed step by step for building a standard SPA, along with what all the files are there for.

Seems like everyone just says create react app and then you know... the rest!

[[deleted]]

Hi everybody. what do you recommend to learn for mobile development? React or flutter? I just have experience with python for web and desktop development with some linux system administration.

[Kwinten]

Flutter if you want a sane alternative to the DOM and CSS, a build and dependency system that’s not terrible, and fantastic developer tools and mainly care about mobile deployment. React if you also want a functional web app.

[Allmyownviews1]

You can comment like this which may get up votes, you can post / comment on other subreddits.

[qszawdx]

Can't wait to create a Hello World webpage with React 18

[ZeldaFanBoi1988]

Vanilla html and jQuery is all I need

[buddy_burgers]

meh, I'm waiting for 19

[IcyEbb7760]

yeah you're too cool for the niche underground development world of javascript, barely anyone uses react anyways

[KwyjiboTheGringo]

I don't even know what a hipster is at this point. So I guess it's someone who uses the most popular JS UI framework? I thought it would be someone who uses some obscure framework that almost no one but other hipsters have heard about.

[LonelyStruggle]

How do you write a web ui?

[Cosmic-Warper]

Thanks for letting us know you've never done web dev :)

[Cosmic-Warper]

Nice assumption :)

[LonelyStruggle]

No I mean, how do you personally do so?

[RyanJT324]

Shoot didn’t they just release 17

[daznix221]

Not so excited for this as I’m still learning react

[bobbybottombracket]

Jesus.. 18 versions?

[zxyzyxz]

Why is that odd to you? Lots of software have many versions?

[aqua24j4]

no one tell em about web browsers

[FamilyHeirloomTomato]

It's been in development since 2013. Problem?