[mbell]

> In React 17, React automatically modifies the console methods like console.log() to silence the logs in the second call to lifecycle functions. However, it may cause undesired behavior in certain cases where a workaround can be used.

I feel like when you've gotten to the point that something like this has been proposed and accepted as a good solution to a problem your framework is facing, it may be a good time to stop and reconsider the approach of the framework.

[btown]

This gets at something deeper: React has a policy of “in the dev environment anything goes; we will mess with your code and its runtime performance to help detect bugs or future bugs; you want us to do this, even if you think you don’t.”

But this assumes good QA and staging environments exist and are used correctly. In reality, many users of React test on local and immediately deploy into production. The more the environments differ, the less friendly React is to these users. Timing issues and race conditions may surface in production. And thank goodness this isn’t Python where a log statement can consume an iterable if you allow it to do so!

And for those saying “Strict Mode is opt-in” - your coworker may opt in your whole app without you knowing it. Hopefully you see the PR or the Slack thread. So much in React now enables this “spooky action at a distance.”

The React team has put a lot of thought into balancing the performance needs of large codebases with the stability needs of smaller teams with less robust SDLC. I can’t think of a better workaround. But it’s still going to cause chaos in the wild.

[andrewingram]

I agree with the sentiment of not being comfortable with dev and prod differents.

That said, with React these dev mode differences are intentionally about making obscure production issues (such as timing ones) rear their ugly heads in development. The goal is that if your code works without issues in dev, it’ll work even better in production. It’s a thin line for sure, but I broadly support the way they’ve done it so far.

[kmlx]

can be solved this way:

- npm start when developing

- deploy on dev using the artefacts from npm run build

builds take a bit longer this way, but it guarantees QA will test using a non-dev build

[KronisLV]

> In reality, many users of React test on local and immediately deploy into production.

> deploy on dev using the artefacts from npm run build

These two statements do not fit together.

I agree that "You should have dev/test/staging/... environments" is the correct answer, but clearly that's not the reality for everyone.

[kmlx]

> clearly that's not the reality for everyone

might not be the reality, but multiple envs is the only correct answer.

[mhoad]

Broadly speaking I think React is in a weird spot where they have painted themselves into a corner with no obvious way of fixing it by essentially forking the DOM and doing so many things independently of the wider web platform. That approach made a lot of sense when it was first released but is just a liability at this point.

If you’re deep in React land and it’s all you know I think 2022 might be a good time to expand your horizons a bit because the landscape around you has changed a lot in the past five years.

[resoluteteeth]

> Broadly speaking I think React is in a weird spot where they have painted themselves into a corner with no obvious way of fixing it by essentially forking the DOM and doing so many things independently of the wider web platform. That approach made a lot of sense when it was first released but is just a liability at this point.

The problems that strict mode is addressing with this somewhat unusual approach have absolutely nothing to do with the VDOM. Rather it is that code using React is subject to restrictions (being pure functions and following the hook rules when using hooks) that are impossible to express or enforce at compile time in javascript.

[mhoad]

Sorry just to be clear, I wasn’t tying this to the strict mode situation but was attaching myself to the concept that this is just one of several points where the framework is showing some signs that it’s time to start thinking about alternatives particularly because I don’t think some of them are fixable at this point, they are just too central to the entire project and those decisions no longer make sense.

[joeyjojo]

Outside of Vue, and maybe Angular, are there any other stable alternatives with a decent ecosystem? I'd love to hop off the React train, but I haven't found anything that compares to the experience of just using create-react-app with Typescript support.

[lf-non]

Try solid.js [1]

I have been using it for a month now and love it. If you are coming from react the API is familiar enough that you can get productive in a day or two. Reliance on observables is a big plus for me (no virtual dom diffing) and the dom reconciliation is very similar to lit. Check out the author's blog posts [2] for more details.

If are into jamstack, Astro [3] has good support for solidjs already and offers an easy way for selective hydration of dynamic parts of the UI.

The component ecosystem is a bit lacking compared to react/vue, but it pairs well with pure css libraries like bulma/daisyui or webcomponent libraries like ionic/shoelace.

And you can also wrap your solid components as web components and use them in a larger app without converting it all to use solidjs.

[1] https://www.solidjs.com/

[2] https://ryansolid.medium.com/

[3] https://astro.build/

[djbusby]

RiotJS and SvelteJS get mentioned as alternates in my circles. I like Riot - but only done it on smaller projects.

[holler]

If you haven't check out ember-cli + ember.js latest Octane release. Full typescript support, thriving community, lots of companies using it, lots of active development.

[sibit]

Any thoughts about [Lit](https://lit.dev/)?

[mhoad]

For whatever it is worth this is the one I am betting on.

[junon]

Aside from the bustling ecosystem, Surplus has been around for a long time, consistently beats benchmarks, and is quite lightweight and unopinionated. I've used it for a lot of projects, small and large, quite successfully.

[reubano]

Have you checked out https://mithril.js.org/

[Pet_Ant]

I remember Ember being solid for a while, but I fell off of the front-end stuff

[captainmuon]

When React first came out, it was a breath of fresh air. There were some weird kinks, but instead of getting better they doubled down on the magic, and it got worse over time.

I would really like something like React, but completely explicit - no hidden state, no hooks, no monkey patching. Everything class based, you have one render method, one method where you can launch your ajax, and you give your data dependencies explicitly instead of React trying to infer something and calling your functions at random.

[KronisLV]

> Everything class based, you have one render method, one method where you can launch your ajax, and you give your data dependencies explicitly instead of React trying to infer something and calling your functions at random.

Class based components in React got pretty close. But for whatever reason, everyone jumped on the hooks bandwagon, against which i have some personal objections: https://blog.kronis.dev/everything%20is%20broken/modern-reac... (harder to debug, weird render loop issues, the dev tools are not quite there yet)

That said, using the Composition API in Vue feels easier and somehow more stable, especially with the simple Pinia stores for data vs something like Vuex or Redux.

[imbnwa]

Reginald Braithwaite had some really great responses to the move away from OOP as well: [0]http://raganwald.com/2016/07/16/why-are-mixins-considered-ha... [1]http://raganwald.com/2016/07/20/prefer-composition-to-inheri...

[afiori]

It would be enough for functional components to have extensible input and outputs

    function Button({props,ref,key,hooks}){
      useEffect(hooks,()=>{...})
      return {render: "text", ...stuff}
    }

[imtringued]

Yeah come on, the global hidden variables are completely unnecessary.

[aaaaaaaaata]

You may just want HTMX, right?

[nightski]

It's not a "solution". It's more akin to a lint rule imho. Javascript provides no language level guarantees. There is no static type checker or compiler to enforce these things. So we rely on linters, tests, and assertions. Yay dynamic languages.

[danabramov]

Thank you for the feedback. I agree this behavior was confusing. (We changed it to slightly dimming the second log in response to the community discussion. This change is released in React 18.) The new behavior seems like the tradeoff we dislike the least but new ideas are always welcome.

Overall, we’ve found that calling some methods twice is a crude but effective way to surface a class of bugs early. I absolutely agree that it’s not the best possible way to do that, and we’re always thinking about ways to surface that earlier — for example, at the compile time. But for now, the current solution is the best we have found in practice.

[tomduncalf]

Thanks for clarifying Dan. I think it might be appropriate for React to console.warn that strict mode is active (in dev mode) with a short description of this side effect, or perhaps the “dimmed” log message could have an explanation after it. Not all users have explicitly enabled strict mode (e.g. in my case I just started a new Next.js project) so this behaviour can be quite surprising and hard to track down why it’s happening.

[danabramov]

The problem with logging a message is that it creates permanent console noise for people who enable it, thereby incentivising people not to. It seems like a small thing but people are very sensitive to extra logs. And if you allow silencing the log, we’re back to where we were.

[tomduncalf]

I guess I was imagining a single warning message at the top, “React is running in strict mode. This may result in you seeing console log messages twice. Read more here. Click here to disable this message for this site. Click here to disable this message globally”. Not too much noise really, especially if you can disable it per site or globally.

I do see where you are coming from, I’m just thinking of my experience where I spent 30 mins+ thinking I’d found a bug or fundamentally misunderstood React all these years or whatever, and it turned out it was just the strict mode - but because I was using Next.js I never explicitly opted in, so had no way of knowing this might start happening (unless I read every release note). I’m guessing a lot of other developers using Next might be similarly confused!

[kristaps]

I agree, at first reading this sounds just plain horrible. I haven't tried doing any research, can anyone point out why it's not?