The Brutal Lifecycle of JavaScript Frameworks

You can still do this with React. Some of the most-common general-purpose libraries for working with React aren't that big and could be written from scratch pretty easily. If you recognize when something's entire purpose is apparently to replicate OO features while staying "purely" functional by jumping through a series of awkward hoops, you can recall that the language you're writing in does, in fact, support OOP, and avoid the library altogether by using built-in language features (I keep seeing this in the React ecosystem and it drives me nuts).

Probably use Redux because everyone and everything expects that you are. It's easy to understand if you ignore their bad terminology and go in knowing it's just an event/messaging system, more or less. Action = event. "Action creator" = anything that dispatches an event. Reducer = your event handlers. Exactly what you'd expect from an event system with centralized event handling. Utterly mundane and non-magical. Figure out how to leverage "combineReducers" to keep your file structure sane and just go. The closest thing it has to magic going on is that when an event comes through it checks to see whether any of the refs in your "state tree" changed as a result of that event, and triggers re-renders on relevant connected view(s) (React views, in your case). That's it. Note that with a very little creativity one can decouple one's Redux code and most/all of one's business logic into its own library to share it between React and React Native.

If you use React Native, you're in for a treat if you're used to fully native cross-platform dev. It really does a great job of rounding off the many, many rough corners on Android that make it such a pain-in-the-ass to work with. Warning: the ecosystem's kinda nutty and does a bad job of keeping in sync, so avoid dependencies that directly target React Native as much as possible if you want to ever be able to, say, upgrade your React Native version without breaking everything. Pure JS libs that have no truck with React Native, good. Libs that add narrowly-scoped extra native integration for RN, usually good. Mostly JS libs that add on to React Native itself, typically just a disaster waiting to happen, no matter how nice they seem at first.

Oh, and use Typescript. For the love of god use Typescript. Just start the project with it, and never look back.

I completely agree. Many people claim the web is overly complex, but then go back into the C++ world where you need a build tool to build your makefile which builds your project using cross compilation on a handful of platforms.

I like to remind people that 10 years ago Android didn't exist, streaming video was still only just becoming a thing, and the iPhone had just been released and wouldn't have an "app store" for another 6 months.

There have been several massive changes to the web and to computers and how we use them in that time. It only makes sense that we will use different frameworks and paradigms to create applications.

So what are we measuring here? It seems obvious that more popular frameworks would generate more questions, but so would:

- Newer ones which not as many people are familiar with.

- Poorly-designed ones which lots of people nevertheless use.

- Ones which disproportionately attract inexperienced devs.

Here's Evan You (creator of Vue) https://youtu.be/D_z-RAweP1k?t=3m9s talking about the tweet.

Brand new frameworks have zero docs and zero questions in Stack Overflow. Older frameworks have (hopefully) complete docs and a library of SO questions. In between you get a gradient.

I'm just not convinced that the data they're looking at means what they think it means.