React created roadblocks in our enterprise app

Is there a Rails for React? I use React+Redux+Typescript and it's nice but I always have trouble setting up a new project.

Rails is magic in that it's all ready. React+Redux+Typescript is great. I just don't want to make decisions here. I want to just make a web app. Like how Rails defaults to ActiveRecord and friends, is there something like that for Rails+React+Redux+Typescript?

I'm looking for:

* Few decisions for me to make

* It's relatively popular enough that there is a community around the whole thing

It's a huge productivity enhancer with Rails to be able to google "Rails do x" and someone has an answer to that. If I had to google "Ruby with X library and Y other library" I think I might commit suicide because the Rust experience is like that: "Use actix-web". Ah, and how do I use that with this other tokio based library. Oh you can't, because you need to make sure the runtimes are compatible.

I don't want all that.

you have to use `npm ci`, which was added a few years ago. my team ran into that kind of issue right after `ci` was added, thankfully, or we would've had to do something similar.

i now have this aliased to `ni`, so i get to say `ni` to the app often.

>React is stable?

Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me.

> the change was far less abrupt, and you can still use functional views if you want to

So you are hating on React because you don't know this, but this exact optional progression has always been how they have introduced new features into React. Again - old code works with new React versions.

> do we really need to ... expect them to know

True, this is a weakness, but the documentation is pretty explicit on this front. It's not like there isn't a big community around the library to address this.

Anyhow, I respect your points here, and concede that writing server-side code in Node is probably not what you want to do; I reach for tools like Hasura in this case regardless. With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster.

> React, since hooks, includes a full state management solution - Context, Provider, and hooks.

Sure, but that hasn't been around even 2 years. Prior to that, there was a different approach and philosophy to doing things. I remember when higher order components were all the rage till suddenly they weren't.

I'm not advocating for stagnation, but at the same time, everything in JS land feels experimental, even in established frameworks, and the entire community keeps marching along as things keep changing. Which if you are a full-time developer doing that, is fine I guess, but it is not the norm compared to pretty much any other software engineering field.

> Second, even if you want an actual state management library, both mobx and Redux are quite stable

I cannot say enough nice things about MobX (although I was using it back when it didn't use Proxies so you had to deal with a lot of cloning back to native JS objects which got a bit ugly at times), and I don't disagree with you on this point for state management, although I personally could not stand redux despite 90% of the community vehemently singing its praise.

> This is a comical take. Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks.

I should have perhaps qualified that better. Yes, I know there are people writing complex apps, but I was viewing it from the POV of a non FAANG type place with tons of engineers to throw at a problem. If I was a single person or a very small team trying to develop something complex, I would place a much higher emphasis on a more stable development environment/language/framework.

> Is it not true the entire ML ecosystem has been reinvented in the last 5 years? My React code still builds & runs from 2016. I really feel like this is a case of "external person overestimates complexity in external domain, underestimates complexity in internal domain" because everything you're saying sounds like you dipped your toes, and didn't actually build applications.

Let's take Pytorch as a comparison framework. It's had tons of releases, but at a fundamental level, the core API has stayed the same. I've ported 3 year old code to the latest version with pretty much negligible effort. And at its heart, it is because APIs are kept very stable and people aren't deciding each year that they need an entirely new way of doing ML or performing automatic gradient estimations, etc.

Similarly with Python... there have been a bunch of Python 3 releases in the past few years but they each add new things that are useful without making big changes that suddenly change how everyone would tackle building a new piece of software.

On the other hand, porting a 2+ year old React app to the latest version of React (along with bringing dependencies along) would be a very painful process. I know this, because we've done this at the company I work at.

There is also this implicit assumption in JS/React land that you are going to come marching along with all the latest changes. Heck, less than 2 years back, their documentation site wouldn't even let you view older versions of React documentation, so the moment they released a new version of React, the docs would only ever show you the new docs. What's funny, is that today they supposedly have links to their older docs...but every fucking link is broken :-/

example: https://reactjs.org/version/16.8

And nobody probably even knows that, because there is a general expectation in the field that everyone just keeps staying up to date with the latest and greatest and deals with whatever pain points come along with that and no one has probably even tried to access older documentations or raise issues about it. Which is fine, like I've said many times before if you've made your peace with it and that is your full-time job, but it is not the expectation or norm in most other fields.

Finally, I should state for the record (because you stated otherwise in another reply to me), that I actually love javascript...well at least ES6+ JS. I greatly enjoy(ed) JS, JSX, developing in VsCode, and even building things with React, Mobx, etc. I'm not a software engineering snob who looks down on JS and the ecosystem. But I also have a more diverse viewpoint because I work at a small company and get to wear many hats and have been able to do lots of different things (ML Engineer, Front-end work, write and deploy pretty complex software, etc.). And while I have a lot of fun doing front-end stuff, It still feels like there is a lot of constant overhead to it, and that is pretty unique to this one field compared to most everything else.

Take a look at Next.js, which incorporates a general-purpose router, does all the Webpack stuff for you, has generally painless server side rendering support (but you can also build a purely client-side bundle), and has direct support for a long list of popular libraries.

It doesn't handle global state, but has tested examples for Redux[1] and various other libs that incorporate the server-side rendering and static site generation functionality that Next.js has.

[1]: https://github.com/vercel/next.js/tree/master/examples/with-...