Hacker News Reader

Comment by joemi | Hacker News Reader

As someone who just decided to learn React (and modern javascript, after 1.5 decades or so of not programming in javascript at all) in the past month or two, I've been extremely frustrated by the documentation (in particular) and the whole state of flux that it's in (in general). When I started with React, all the tutorials/guides on the site said "this is the old documentation, it's about to be replaced" on every single page. Still I worked through it and learned a bit. But by the end of working through it I figured "well, I might as well click the link that's on every page and see what modern React is like". So I tried to follow one of their guides and had issues with the very beginning. But I knew enough React to know what to do to fix the issue, so I did, and proceeded with the new guide, only to hit more problems immediately after that. So I gave up, and just stuck with the "old" way to do React. But then just 1 week after all those issues, the new docs were switched over to be the main docs. I'm honestly kind of afraid to try to work through them again and see if they fixed them already.

And now I just read this article, and, well, I'm even less motivated to get into this stuff. Is this just a really bad time for React? Or is it always such a chaotic changing climate around it?

View on HN

Unpopular opinion: like most frameworks, things are moving far too fast to be beneficial. I've been in the development community since the mid-late 80s, and I've been a web developer since the early 2000s, yet I still cannot keep up with the latest and greatest from the technologies I work with, which change both one job to the next, as well as one project to the next in many cases.

Angular lost me going from 1-2, for example. Not because Angular 2 was bad, but because they decided they needed to do a fresh start. Vue2 -> Vue3 is almost the same story, though I stuck with that one. Rails? Oh boy...PHP? That is a damn nightmare. Tell me without looking at the docs what the best practices should be for even the most basic stuff.

If I have to rewrite large portions of my code for a new revision, even a major one, you are most certainly doing it wrong. If you want to rewrite the project, at least care to add a compatibility layer (which some projects have done, but most have not).

You're not wrong, you have to be pretty invested to keep up to date with most technologies.

There's even a new crop of frameworks coming up now, like Astro, Qwik, Solid, etc. Plus a paradigm shift towards MPA and abstractions like server components.

You only need to care about those if you need to find a new job though, at least until they make a dent.

The really frustrating part to me, is that every year the frontend claims they have finally slowed down and that things are stable.

I just did the "create-next-app" and, I can't claim that all of that is not eventually needed in some form or the other; however, it is mind blowing that I think I know how to hello world a video game with less crap here.

That point is crazy to me. Yes, if you are making a multi platform game, you will need a ton of boilerplate. Will far outstrip the boilerplate that this react thing gave me. Same for if you have a large team building a web based application.

However, for dipping your toes in to the frontend part of a web page, it is boggling to me that they also push so much on you that are not directly front end concerns. Worse, there is a ton here to help with "fast" web pages. Problem is, most of the slow pages out there are slow because the teams just can't keep up with all of these shifts in how you are supposed to do things. Every page that is actually fast, simply stayed with how to do things years ago.

>Problem is, most of the slow pages out there are slow because the teams just can't keep up with all of these shifts

Not really. Most pages are slow not because they're using outdated techniques, or they're still serving everything from a large Windows Server running an ancient version of .NET. Those old react pages aren't slow either because they "didn't keep up", they still run fine.

Pages are slow because of the obscene amounts of tracking and "user conversion" techniques. Banners, notices, trackers to make note of everything you do on the page, trackers to make note of errors, third party trackers, ads everywhere because a simple static one isn't good enough, list goes on.

Guess what those old pages that "stayed fast" don't have? You guessed it, all those BS trackers, they weren't readily available back then.

I didn't mean that old react pages are slow. I meant sites that started on old react and kept trying to keep up with all of the newest best practices throughout the years are slow. Typically because they do too much on the webapp and don't treat it as a gui only. The last web app I looked at in the old job was literally as much code as the entire backing service for it. I don't know how to justify that.

And yeah, for public sites, tracking almost certainly dominates how slow things are. I was thinking of internal tooling sites. I remember how fast many of the tools were when I started at the last job. I also remember how slow all of them were getting as I was leaving said job. It is more than a touch insane.

The backend doesn't have to do things like respond to user events, persist state, do validation while typing, handle modal dialogs, etc.

Sorta? The backend specifically exists to be where state is persisted. And the validation of the data has to happen at the backend, even if you also repeat it at the front end.

You are correct that there can be more interactions on the frontend, but frontends were both faster and easier to deal with when they did not do all of this. For many internal tools, bouncing back the validation from the backend is also easier to understand than the validation that the website is providing.

I suspect it is a bit of a curve. Zero interaction on the front is not pleasant. All of the state replicated on the front is also not useful and likely to be more problematic.

Then go back and use ASP.Net 2.0 and submit a few mb of view state for every user action. Or Blazor server rendering.

If you are pushing megabytes of state for every user action, you've made plenty of other mistakes along the way

And I know it is more than a straw man. There really were bad sites like that. We have swung to another side of bad code, though.

That's how server-side interaction was in the early 00's with ASP.Net WebForms. This type of interaction is one of the things being proposed as opposed to client-side. And yeah, it definitely was a (very painful) thing. Server-driven Blazor has very similar (poor) behavior today. I know there's other frameworks that do similar things. Which really sucks if you have any latency or bandwidth issues.

Not that I like the idea of several MBs of JS being sent over the wire either... I know that is also a thing, not to mention poor state mgt, which is also a regular occurrence (most angular apps have many state bugs).

Personally, I'm not too bothered by client rendered/driven apps... They can often be split accordingly, and it's reasonable to stay under 500kb JS payload for a moderately sized web application. Not that everyone has as much awareness. I think of the browser as a thick-ish client toolkit as much as it is a rendering platform. That doesn't mean SPA is the right way for everything. I wouldn't do it for a mostly text content site (news, blog, etc). And most of my work is web based applications, not text driven content sites.

I can't say I've come across many internal tooling where the experience is anywhere near as bad as public sites. I find that even the cheap hardware offerings from businesses tend to handle bloated internal tooling pages fine, even if your first load might take a good minute. Ignoring tooling specifically crafted for IE6 and hasn't been touched. May that rot in hell.

There was this really horrific one I did experience, come to find out the entire company is relying on this angular app that connects to an ancient mac mini that IT is responsible for but mostly forgot about. Wasn't a large company, but they weren't stalling in growth!

Certainly many sites with tons of tracking are worse than most internal sites. You will not get a disagreement from me on that.

I can't really cite examples, as I'm not at the old job. But silly things like our "news" homepage was getting so that it lazy loaded all of the news. HR things would load in parts, too. And issue tracking seemed to constantly be a mess.

The tool my team controlled had bloated to excessive points. Some of that was almost certainly my fault. I had designed a somewhat granular backend. That said, I remember things were certainly faster before we had a ton of redux based code to do things.

Explain Jira then.

There's an effect (sic) from having open source and ubiquitous internet that makes everybody react (sicsic) to everybody whenever something is seen as the new way.

Before that you had 2-3 years of stable blindfolds before knowing what the other teams cooked secretly.

I agree 100%. Framework devs forget that the rest of us have real jobs to do and can't spend weeks updating to the latest version of the framework every 6 months.

The job of framework devs (at least the ones working for companies on those frameworks) is to make it seembusy and evolving, even if that’s not needed; if a framework is ‘stable’ and ‘done’, contributions drop fast and the project dies. People, for some weird reason, don’t see it as an advantage where a project on GitHub has only security and dependency updates but is done feature wise.

Those of still using Django are quietly enjoying ourselves doing things in fundamentally the same way for the past decade.

.NET is trying to move fast and break things, however most devs are using it like they had in the past 15 years (with some new best practices for c# and frameworks); it's lovely working on that. Updating libraries is painless, even for projects > 5 years old. Try that with npm... After 5 weeks.

The Angular API has been pretty stable for the past 6-7 years since v2 (well, since v4 if you count the Router changes), and the upgrade process between major versions is pretty smooth. Especially since the Ivy release, they've matured a lot... That's one of the reasons I still prefer it over React, especially in enterprise settings. (Although with their latest versions they are again trying to keep up with the cool kids by introducing standalone components and signals... not sure what to think about that yet)

I completely agree with this..

I have been trying to get into front end JS development and it feels like every guide is broken within 6 months... When I actually succeed at one part, I then realize that to add testing, or bundling, I need to follow this other guide, which isn't stable anymore, and then breaks the whole project. I have tried 4 or 5 times now trying different frameworks and "quick start" features or following recent YouTube videos, giving it 3-5 hours each time, and I can't get a working typescript based UI + test + bundler to work.

Edit: I should say, I'm open to any _working_ guides that go from start to bundle that you all know about...

This definitely doesn't just apply to frontend. A lot of the JS ecosystem can be like this :(

Too many projects. Not enough focus. Everyone creates their "alternative".

This is the easiest way I know to get a React app up and running. https://ymse.io/blog/how-to-create-a-minimal-react-app/

> As someone who just decided to learn React (and modern javascript, after 1.5 decades or so of not programming in javascript at all

Sorry you're experiencing this. It's not "just React" though, it's pretty much all Javascript (or Typescript) now. Especially front-end, but I swear, JS/TS on the front or back is like trying to learn to drive a car in heavy traffic while also repairing the brake lines which are malfunctioning

Saying it's not "just React" is normalising the problem, which I think really doesn't benefit React trying to set itself as the de-facto standard for front-end code.

De facto what...? Maybe if you only read Twitter. There's tremendous amount of work in other libraries too.

I would also argue that poor web standards support hinders the future of React, especially for web components.

I love your analogy. That's definitely how it's felt for me.

It is also not just JavaScript, but also with current AI technologies, which arguably, change even faster than JavaScript. You see, fast changing technology does not imply the underlying tech is bad, but rather there are unexplored new ideas and there are enough interested people ready to dive right in. Yes, it is exhausting to follow. Yes, it is frustrating when the floor shifts underneath you. However, dismissing a tech just because it is fast changing is not a good altitude.

Going to train an AI to write JavaScript frameworks.

For context I'm a specialized back-end (but with a lot of experience in desktop GUI/game engine stuff) dev and I also wanted to learn React recently to round off my skills and be more marketable in the job market.

Like yourself I also prefer written docs, but trying to find such structured info was an exercise in futility. At the end I used my existing Pluralsight subscription and went through the React 18 path they have which is around 18 hours or so in total. The courses covered different topics around React like components, hooks, testing etc. Good thing is the courses also have full transcripts! I followed them along and created some small apps myself in the process. Now I'm pretty much sure I can handle working with React in a normal job setting. You might want to consider that option. To be honest FE seems like programming on easy mode compared to some of the things I'm used to working on in my day to day. If you are an experienced programmer you should have no problem getting caught up to speed on that relatively quickly.

You’ve basically said that you did a React course, built some toy apps (which almost certainly had sterile, malleable requirements) and now feel like the whole “front end” thing is easy mode.

Chances are you aren’t materially smarter than the hoards of smart people doing this day-to-day and find it ‘not-easy-mode’, and that you’re instead in deep Dunning-Kruger territory.

You watched the VHS about foundation repair but you’re yet to get thrown off-course when you find out that you don’t know what carbon-fibre stucco lath is.

A more charitable interpretation is that _hao has learned that React has simple, easy-to-remember patterns, allowing the developer to focus on domain-specific problems (which can be arbitrarily deep and complex, just like backend code.)

Not to be combative, but I didn't say anything about being smarter or master at web FE and React. My comment was supposed to be seen as more like how @hathawsh read it. It's easy to do work with React if you have a good programming background and it doesn't need that big of an investment of time to go into it.

I'm sure React has it's own intricacies just like every other tool and it takes time to appreciate those. I can see how managing your reconciliation state can become a big hurdle in larger projects for example. I've done WPF, MFC and a lot of other things on native desktop programming and the ideas in React are not that different. Those ideas in the browser context are actually easier to deal with than on a native platform hence my "easy mode" thought.

Agreed... I've done a bit of simulation work, and the unidirectional flow for react (and redux) was pretty natural to me and similar to other approaches I'd used for ui composition and state management. A few patterns that can be more difficult (slightly/arguably) to get started with, but easy to repeat.

I've been a fan for several years now, almost a decade and I adopted the hooks relatively early on as well. It feels right, even if something under the covers are complex, you don't have to think about a lot of that when you aren't looking at it.

Similar experience, frontend work is more relaxed and forgiving. You can more or less trial and error until it works and looks good. It's all very visual. On the other hand, making a mistake in your backend auth, order handling/accounting or even mass email efforts can have some really nasty results.

I write React but don't look at the docs much so I am not familiar with all the changes there. The basic concepts of React haven't changed much over its history. Hooks are newer than class components, etc but class components still work. Hooks have been out since 2019 so they aren't exactly new (and they were in the old documentation). React itself has been quite backwards compatible.

The Javascript ecosystem tends to have lots of flux with new libraries and ways of doing things coming out all the time. I have found React to be one of the most stable libraries around. I can update versions of React and my code continues to work as before. Libraries that I depend on tend to have more issues with this and version updates can mean changes in the API for the library or a newer version of React not being supported.

My suggestion for someone learning React would be to start with the simplest way of getting started and learn React before learning concepts brought in with frameworks, etc. If I were to start learning React today, I would start with Vite.

In the end it's all state -> view -> interactions -> state -> view -> interactions.

Svelte does it most simply though. I've been doing React for years now, but it still feels ridiculous to me compared to Svelte and others.

I honestly think people who like React have Stockholm syndrome. And everyone is taken hostage since it's the most popular one. UseEffect is ridiculous, hooks in general are ridiculous, mapping over array to create elements is ridiculous, having no tools out of the box for JSX to do simpler if else, for loops, etc. All these bizarre concepts just to hack around JS to make all of it work. And in the end it's all very difficult to read and reason. And all this bizarre boilerplate is just tech debt. It does nothing to describe what is actually going on in that component.

React is a lot better than what came before it (Angular 1, Backbone, jQuery), etc. And I think it's longevity is in large part because it hit the "good enough" where the frameworks ceases to be a major barrier to productivity.

The newer frameworks (Svelte, SolidJS, etc) definitely seem to improve on React. But it will take some time for the wider ecosystem of libraries to catch up (and ideally for one of the newer frameworks to establish themselves as the next-gen "winner)

Doing frontend in this day and age is like doing agility with your dog. And people who've been doing frontend for a while are so conditioned that they see this as normal. "Why would want to just go to park," they ask "when you could do agility course? It's not hard, the are hurdles, yes, but it's fun and it's not really complicated once you do it twenty times."

Very peculiar analogy but yes I’d just prefer to go to the park with my dog, as you say

> As someone who just decided to learn React (and modern javascript, after 1.5 decades or so of not programming in javascript at all) in the past month or two, I've been extremely frustrated by the documentation (in particular) and the whole state of flux that it's in (in general).

As someone who was in a similar boat (2 decades of .Net essentially, with a lot of HTML/JS but no frameworks), I found jumping into Angular very nice in this regard.

New versions every 6 months but not with "changing things for the sake of change", actual small but incremental improvements. The documentation I've found to be great, and since it is "opinionated" it easy to jump between multiple projects and not feel completely lost.

It seems a lot of flak that Angular gets is because it is "opionated" but I look at this as a major positive.

I've jumped between React projects and have been bewildered at how different they all are.

The whole framework vs. library thing.

The problem with Angular (back when I used it, around versions 4-6) was that it had a ton of opinions, and they were half baked. Angular had its own plugin for driving flex layouts, and roughly 90% of the bugs we had were related to one of those plugins.

Another problem I've seen is that the default data binding being taught to new comers is slow. At least slow enough for a team I was on to later have switched to an approach (called OnPush) where you must manually tell the UI when to update with calls to detectChanges() all over the place. The way to avoid that is to fully embrace Reactice Extensions, but that seems to be very hard to grasp for a lot of developers that instead work around the library in all sorts of quirky ways (subscription()'s everywhere, that you must remember to dispose, that calls detectChanges()....).

Edit: Found this old GitHub issue I stumpled upon when looking up why this performance improvement wasn't the default.. I think these comments are interesting:

> Both OnPush and zone coalescing would, however, change the default semantics of building Angular apps. This is outside the scope of the feature.

> We did discuss this a couple of months ago and felt that we shouldn’t since it would complicate things for new user which are not familiar with change detection.

https://github.com/angular/angular-cli/issues/21278

You are probably talking about rxjs, possible even ngrx.

I have become to love it.

However, it should be way simpler now with the upcoming Angular version that's supporting signals now.

Yes, the rx in rxjs means Reactive Extensions. I think it's perfect for UI dev, but the steep learning curve excludes a lot of developers.

Signals look identical to React hooks.

Regarding the flex layout thing, they decided to deprecate it.

https://2022.ng-conf.org/a-new-layout-ahead

More recent versions (I'm currently on 15) don't seem to have these issues, as least from my working with them. I started an enterprise product on version 13, the upgrade path to 15 has been smooth and so far, so good.

> is it always such a chaotic changing climate around it?

The old doc was like 10 years old, they just officialized the new one this week.

Create React App was the recommended way to build a React app for like forever but Facebook stopped maintaining it 2 or 3 years ago. The drop-in replacement is Vite.

CRA is deprecated? Glad I switched to Vue a while back, jeeze.

CRA was always terrible. But React without CRA is fine.

Yeah I stopped using CRA when they had known critical vulnerabilities in their dependencies and their reaction was essentially the shrug emoji.

Welcome to the club. Relax, the pain eventually passes. After you leave webdev, never before that.

This is not a problem specific to React, it seems to be a problem with the industry as a whole. I had this problem with Cloudflare, AWS and others. Documentation is old, inaccurate, software is unstable, etc... These companies keep pushing features like startups while breaking everything up and not fixing the old stuff or maintaining it.

And have you checked Web 3.0?

Try out https://vuejs.org/

It’s simpler to learn. Guides are phenomenal. Creator is a designer and author of Vite.

React is great in that it’s being developed by a great team of diverse engineers. However diversity comes with differing opinions of end user experiences.

In the world of product development and innovation, the role of a designer is often more impactful than that of an engineer, especially when it comes to shaping the overall user experience.

Designers possess the unique ability to understand the end user's needs, desires, and challenges, translating those insights into functional and aesthetically pleasing solutions. Their holistic perspective allows them to balance form and function in a way that elevates the value of the end product.

While engineers excel at the technical aspects of a project, ensuring that the underlying systems function properly and meet performance specifications, designers take a more human-centered approach. They focus on usability, ergonomics, and aesthetics, often serving as a bridge between the technical and the emotional aspects of a product. This ability to understand and empathize with the user is invaluable, as it ensures that the product not only performs well but also resonates with its intended audience on a deeper level.

Collaboration between designers and engineers is crucial, as their combined skills and expertise can lead to groundbreaking innovations. However, it is the designer's intuitive understanding of the user experience that often plays a key role in creating a product that stands out from the competition and truly resonates with consumers. By prioritizing the needs and desires of the end user, designers help to create products that are both functional and emotionally engaging, ultimately enhancing the overall success of a project.

Thus why the more granular and slower approach such as Vue is what I think is software framework done right.

Actually building in React nowadays is really easy. You just need six hooks, useReducer - for the reactive state, useRef - for the imperative state, useMemo, useCallback - for memoizing state/callbacks, useEffect - for side-effects, create/useContext - for contextualizing states. If you're able to grasp it, you can build any application you want – it only has these hooks on top and returns JSX to execute all of the logic in the most efficient way in terms of rendering. Basically, you don't need anything else, and the signature for hooks is stable for years. What makes it harder to navigate is the infinite libraries and frameworks to choose from, but the vanilla part is a really pleasing functional JavaScript experience, with some learning curve, but greater returns.

Really understanding those properly and deeply can take a lot of time, though. I've been using it professionally for almost two years at this point and some of those hooks I'm still a bit shaky on (although we don't use them that often, and probably less often than we should). And I just learned a couple more new things in the 'You might not need an effect' article that was posted here the other day (I already do most of those, but not all of them).

And I manage several junior developers and I've seen them struggle to understand all of these, even over many months including pair programming and code review feedback.

That being said, I was able to jump into an existing codebase and be useful in about a week with very little prior knowledge of React (just some dabbling in React Native pre-hooks), so I don't think it's hard to learn enough to start doing useful things with it, especially if you already know Javascript/Typescript.

And I would agree that I've struggled much more with other React libraries than core React itself. It's been a long time since I've had to look anything up for core React hooks, I can write lots of React code (in Typescript) and be relatively confident it will work as intended, barring some dumb mistake I made or a misunderstanding of how the data flows in the existing codebase, as long as it compiles.

Agreed, it employs a lot of good functional concepts and shifts you into another kind of "reactive" thinking, where the render function is a pure representation of its state. This actually allows you to "declare" your state and its mutations in a way that perfectly executes your business logic and presents it in a single pure function, but generally, it's hard to think with pure functions for some reason, and side effects are imminent, as well as some asynchronous black-boxed action takes place. Actually – for many, side-effect becomes a patch for conceptual blanks in knowledge about functional data flow in its pure form, and you can tell who really understands it just by looking at his side-effect usage. In the end, what makes the library so appealing is that you need just 6 basic hook functions aligned together in a proper way to describe any kind of state and functionality user interface needs, and it actually performs top-notch and takes little space.

Flux? Javascript has been "fluxing" for almost 30 years. Unpleasant chaos has to become your friend.

It is really unappealing and driven by "smart" people.

1. The "tutorials" are terrible. 2. The tooling - webpack etc - is terrible. 3. Things change too quickly. 4. There are an absurd number of technical layers trying to make frontend "safe" like backend EG typescript.

I like react as long as I am the only author involved. All the FE devs I've been forced to work with pull in an asinine number of external dependencies, weave painfully elaborate webpack setups, among many other things. I can't stand it.

I've had a similar time reading the Firebase docs for Swift and SwiftUI!

Just learn javascript, or better, typescript. It's a fine language and you can do a lot of things on its own.

I've have some side projects in typescript, e.g. https://aperocky.com/cellular-automata/, and none of it needed react or any of the common frameworks. Just pure HTML and javascript, turns out it's not that hard.

I would checkout Vue. It's much more user friendly IMHO.

I think it depends on the developer. I started with Vue and loved it for a year, then decided on a whim to look into React. This was just after hooks were released. I love React – never looked back.

I gave up on React 5 years ago for this very reason (and others)...it sounds like not much has changed, and it's still a constantly changing minefield.

I've had much better mileage with Vue.js - far more opinionated (which I like in a framework).

That is a world full of marketable-skill-hype. Pity you didn't started with Svelte.

Start with The Tao of Redux

Redux is so painful to refactor, it makes my head explode. I don’t trust any tech that makes refactoring so painful

It might seem chaotic to you, but the docs change has been a long time coming, and isn't a surprise to anybody.

> Is this just a really bad time for React

There are some concepts you may struggle with. That's to be expected.

But the new docs don't represent negative change. The old docs were not representative of how most react is written today. That was really confusing for newcomers. There's nothing "wrong" with doing it the old way, but most jobs that use React are going to require you to work with hooks in some capacity.

How deep in the React ecosystem do you have to be to NOT see that the problems OP is describing are not inherent in change, but rather Meta deprioritising public / open-source React?

You wouldn’t see this shit otherwise.

Especially with Meta’s resources, there were MUCH better ways to handle React’s documentation situation. The JS community, but especially React, just happens to set the bar on the floor as far as end user communication goes, compared to other open-source projects, say…Django, with like…two paid staff and a bunch of volunteers.

This isn’t just the cost of progress. It’s laziness.

Reply on news.ycombinator.com