Kivy: Cross-Platform Python Framework for UI Development

* The natural JS leakiness gets amplified if a leaked part references any Java object.

> Performance suffers whenever any native API gets called from a JS loop, as exporting Java's objects into JS, and accessing them is very resource intensive. The only way around it was to move loops to Java side of the code.

One of the gotchas around nativescript (and react native) was that trying to do intensive calcuations was never supposed to happen on the main thread. Nativescript was first to add support for background workers[0] which alleviate this.

I do believe of course that you found CPU intensive tasks/looping to be slower on the JS side of things though.

> Flutter is not much better, though feels to be a bit more professionally done. It's too a memory hog, it's too a CPU hog, and it's still gets way more issues over a native app to warrant its use just for economic reasons.

This I'm somewhat surprised to hear, I thought it would have been way better on the memory side of things since Flutter is essentially a rebuild-the-world approach.

> RN also shares the same Java-JS interop issues as NS.

This is inline with what I expected -- the thing about RN when I tried it was that it just didn't have the ability to access native objects from JS as if they were JS objects. Maybe that's changed since I last tried it.

[0]: https://docs.nativescript.org/core-concepts/multithreading-m...

Back when I tried it, it also had a much more incomplete ecosystem, though the google marketing machine was in full swing. I remember not being able to even use the sqlite library without actually spinning up an emulator (as in, I couldn't use it with just plain dart). Dealing with generics was actually difficult/painful (as in just something simple like printing JSON). BLoC seemed like a hack and was more complex than I was comfortable with for using at large scale. Maybe it's better these days.

I will take Typescript over Dart all day every day. I would even take JS with all it's warts over Dart.

That said, Flutter I think is amazing because it is probably going to be hands-down the easiest way to write apps that hit a large number of screens. I think Google will get there first-ish (they have a lot of money and a lot of platforms to support).

Vue2 worked a different way from inception (probably gaining from being able to see what react did and do something different), it tracks dependencies via the data property, so it does not require you to specify manually. Heavy list rendering isn't what I was referring to, it's manual dependency tracking -- there's a separate pattern for large list rendering.

It's not all sunshine and rainbows, but this is a better default.

> I honestly wouldn't know or care if the library has been "rewritten", "extended" or "patched" or what they've done to the underlying code - because the core API has not really changed in years... Like I said, hooks extended the library and developers could transition at their own pace or not transition at all.

As recently as October this year breaking changes were an issue[0].

> There are many React codebases that don't use Redux. But it's still a great state management library (or pattern) for moderately complex UIs. If you have your own state-management solution (including "simple AJAX calls", whatever that means in the context of Flux or state management), you can use it...

No it's not, and that's the thing. There are even more codebases that are doing just fine with services + views (popularized by angular, ember). The main benefit I see is the time-travel property of state stores, but that's not that hard to do with other approaches either. This is the cargo culting in action -- everyone just assumes "oh you need state-management? well redux it is then, start reading up on reducers". Redux is so obtuse that redux-toolkit[1] exists. Again, the promise was simplicity but what you got was complexity.

> Ditto for React... Any semi-competent dev can be writing at least presentational components with basic network calls in a day... Moderately complex state management and asynchronous actions that affect state take longer to wrap your head around, but I doubt that Vue really simplifies this. UI programming can become naturally complex under certain requirements, and I doubt there is a framework that can completely abstract away this complexity.

So that's the thing, all that "moderate complexity" stuff you'd have been up and running with in Vue 2 on the first day. You can read the Vue docs in a few hours, and write an app that handles state reasonably well in that same day. It's not that it's abstracted away, it's free of unnecessary abstraction which is what makes it simple.

> That's Create-React-App, which completely abstracts the need for pretty much everything except React-Router (10min to setup) and Redux (which nowadays you can substitute with plenty of alternatives). You can be writing business logic and views in 15 minutes, tops. And in a fair amount of cases, CRA stands the test of time, too: I've got code in production for very large customers using it and I know of startups that are building complex products in their second or third year of operations and haven't even ejected their app...

Here's another red flag for me -- if your library needs me to download a zipfile with everything pre-setup (because not doing so would be difficult), then your library is complex. Maybe I'm the only one that still creates new folders and puts files in myself, but I try not to allow this kind of complexity.

I want to be clear -- I don't doubt react's usefulness to enterprise. I do not doubt it's production worthiness or ecosystem -- the result of the hype and the popularity is that people have made it production ready, contributed an intense amount, and built great stuff with it. It is the premier front end component-based library, I do not doubt that. It essentially re-introduced the idea of component-based frameworks (I'd argue Backbone Views were already there, as well as Angular Directives, some MVVM stuff etc), and made is seem simple and sexy.

> Sure, there are network effects - popularity begets popularity. But surely a library or framework can't live on hype alone? Look at Angular... React also - mainly, rather - remains popular because it has seen significant improvements to its core and ecosystem.

You're right, they can't but I think it's more of a case of Angular2 being a failed migration (and maybe apply/digest being horrible there too), it was the enterprise choice before React. I think you have it backwards -- react receives significant improvements to it's core and ecosystem because it is popular, and maintained by a large FANG company. It has endured rewrites (which take significant manpower) smaller projects could not undertake because of said funding.

Funnily enough, this brings me back to Dart -- Dart1 was a trainwreck, and Dart2 is way better but in my opinion is trash in comparison to newer statically type checked languages designed around the same time (Rust, Go, Swift, D, etc). I know however, that Dart will never die, as long as it is used in Fuschia or at Google in general. People were probably saying the same kinds of things about Dart1 and they'll say nice things about Dart2, but I still prefer Typescript because it a type system more suited to my tastes.

I don't think I can convince you that react is complex and has warts that other libraries (in particular Vue) don't have. It sounds like you're productive and find it easy, that's great by all means use it -- whatever makes you the most productive.

[0]: https://reactjs.org/blog/2020/10/20/react-v17.html

[1]: https://redux-toolkit.js.org/