Kivy: Cross-Platform Python Framework for UI Development(kivy.org)
kivy.org
Kivy: Cross-Platform Python Framework for UI Development
https://kivy.org/
58 comments
Nativescript is fantastic -- I maintain that it's better than React Native because React Native lacks a native JS->platform translation layer and React-land is crazy sauce, and can't really be compared with Flutter (because of how Flutter works), but I still think it's better there even because I'd pick Typescript over Dart, and I don't have to commit so hard to the ecosystem.
I've used Nativescript in production and it was wonderfully productive. I think it's biggest weak point is suffering from lack of recent support/ecosystem that hype usually brings.
The ability to use your frontend framework of choice (Angular, Vue, Svelte, Vanilla JS) is awesome, and I think can be incredibly productive for businesses (turn your frontend devs into mobile devs).
I've used Nativescript in production and it was wonderfully productive. I think it's biggest weak point is suffering from lack of recent support/ecosystem that hype usually brings.
The ability to use your frontend framework of choice (Angular, Vue, Svelte, Vanilla JS) is awesome, and I think can be incredibly productive for businesses (turn your frontend devs into mobile devs).
> React-land is crazy sauce
In what sense?
I develop my front ends primarily in React, and other than hooks - which a lot of people have adopted anyway, and only extended the lib - the API seems very stable. The 3rd party library ecosystem may be wild because React is superpopular and people are publishing npm packages with half-baked solutions of dubious utility, but there's always a good library or two for 95% of tasks (good: regularly maintainted, fully-featured, well-documented, tested, typed, etc.).
I don't have any experience with RN so I don't know how things are there, but your comment seems to be about the React ecosystem at large and doesn't correspond to my experience at all.
In what sense?
I develop my front ends primarily in React, and other than hooks - which a lot of people have adopted anyway, and only extended the lib - the API seems very stable. The 3rd party library ecosystem may be wild because React is superpopular and people are publishing npm packages with half-baked solutions of dubious utility, but there's always a good library or two for 95% of tasks (good: regularly maintainted, fully-featured, well-documented, tested, typed, etc.).
I don't have any experience with RN so I don't know how things are there, but your comment seems to be about the React ecosystem at large and doesn't correspond to my experience at all.
I wouldn't consider myself a React expert because I basically stopped using it or recommending it once Vue came out, but stuff like:
- Needing shouldComponentUpdate to do anything nontrivial (it's a bad sign for what should be a library if people make "X demystified"[0] posts).
- The sheer amount of times React has been basically rewritten, with
- Hooks (to be fair Vue has this too, and it's not actually a bad feature, but as usual React introduced it in a near inscrutable way).
- Every react codebase cargo-culting into Flux (normally through redux) when all you really need most of the time is a simple AJAX call.
React had the initial idea, but it just feels like the stuff that came after (Vue in particular) delivered better on the simplicity we all wanted. There are so many little gotchas all over the place that people just paper over/memorize, when Vue 2/3 basically works as advertised right out of the box, need(ed?) less hacks, and you can get reasonably productive and performant in <1 day after reading all the docs.
Also I want to point out that "react" is almost always react + redux + react-router + webpack at the end of the day. The combined complexity is not worth it when compared to Vue in my opinion. These days if I want to use something, I do vue + vue-router + parcel and call it a day, and get productive much quicker though the ecosystem isn't quite as big. For uber-simplicity I like mithril[2][3] though -- but it falls down when you start looking at advanced features like SSR/rehydration.
React has the best third party support/ecosystem because of the amount of hype and OSS friendly companies that are using and benefiting from React. It also is the best corporate choice -- react developers are more fungible, you will benefit from more of the free work done by the F/OSS crowd, etc.
[0]: https://www.freecodecamp.org/news/react-shouldcomponentupdat...
[1]: https://backbonejs.org/#View
[2]: https://github.com/MithrilJS/mithril.js/
[3]: https://github.com/MithrilJS/mithril.js/issues/1838
- Needing shouldComponentUpdate to do anything nontrivial (it's a bad sign for what should be a library if people make "X demystified"[0] posts).
- The sheer amount of times React has been basically rewritten, with
- Hooks (to be fair Vue has this too, and it's not actually a bad feature, but as usual React introduced it in a near inscrutable way).
- Every react codebase cargo-culting into Flux (normally through redux) when all you really need most of the time is a simple AJAX call.
React had the initial idea, but it just feels like the stuff that came after (Vue in particular) delivered better on the simplicity we all wanted. There are so many little gotchas all over the place that people just paper over/memorize, when Vue 2/3 basically works as advertised right out of the box, need(ed?) less hacks, and you can get reasonably productive and performant in <1 day after reading all the docs.
Also I want to point out that "react" is almost always react + redux + react-router + webpack at the end of the day. The combined complexity is not worth it when compared to Vue in my opinion. These days if I want to use something, I do vue + vue-router + parcel and call it a day, and get productive much quicker though the ecosystem isn't quite as big. For uber-simplicity I like mithril[2][3] though -- but it falls down when you start looking at advanced features like SSR/rehydration.
React has the best third party support/ecosystem because of the amount of hype and OSS friendly companies that are using and benefiting from React. It also is the best corporate choice -- react developers are more fungible, you will benefit from more of the free work done by the F/OSS crowd, etc.
[0]: https://www.freecodecamp.org/news/react-shouldcomponentupdat...
[1]: https://backbonejs.org/#View
[2]: https://github.com/MithrilJS/mithril.js/
[3]: https://github.com/MithrilJS/mithril.js/issues/1838
These points hardly justify how one could casually that drop React land is "crazy-sauce" while recommending NativeScript... There's quite a bit to address here:
> Needing shouldComponentUpdate to do anything nontrivial
I'd need to see what "non-trivial" means, because I have barely used it in three years pushing React to production, even when I used classes... The article you post is from 2017, it shows an optimization for a very particular scenario (rendering a list of 600 items), which BTW, could be optimized in many different ways... If you're telling me Vue never needs this kind of optimization for heavy fronts, I'd have a very hard time believing you.
> The sheer amount of times React has been basically rewritten
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.
> Every react codebase cargo-culting into Flux (normally through redux) when all you really need most of the time is a simple AJAX call.
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...
> you can get reasonably productive and performant in <1 day after reading all the docs
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.
> Also I want to point out that "react" is almost always react + redux + react-router + webpack at the end of the day
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...
> the amount of hype and OSS friendly companies
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.
> Needing shouldComponentUpdate to do anything nontrivial
I'd need to see what "non-trivial" means, because I have barely used it in three years pushing React to production, even when I used classes... The article you post is from 2017, it shows an optimization for a very particular scenario (rendering a list of 600 items), which BTW, could be optimized in many different ways... If you're telling me Vue never needs this kind of optimization for heavy fronts, I'd have a very hard time believing you.
> The sheer amount of times React has been basically rewritten
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.
> Every react codebase cargo-culting into Flux (normally through redux) when all you really need most of the time is a simple AJAX call.
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...
> you can get reasonably productive and performant in <1 day after reading all the docs
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.
> Also I want to point out that "react" is almost always react + redux + react-router + webpack at the end of the day
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...
> the amount of hype and OSS friendly companies
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.
> I'd need to see what "non-trivial" means, because I have barely used it in three years pushing React to production, even when I used classes... The article you post is from 2017, it shows an optimization for a very particular scenario (rendering a list of 600 items), which BTW, could be optimized in many different ways... If you're telling me Vue never needs this kind of optimization for heavy fronts, I'd have a very hard time believing you.
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/
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/
Progress is no Facebook/Google/Microsoft, but it's good that there's someone actively working on the framework. Shame they haven't tried to market NativeScript as an alternative to React Native.
At least it's better known that other random enterprise cross-platform solutions that seem to exist only on SEO-optimized listicles of cross-platform solutions such as Codename One, RhoMobile, Kony, Framework7, - e.g. https://www.way2smile.ae/blog/cross-platform-mobile-app-deve... (Again, what companies are actually building apps with these things?)
At least it's better known that other random enterprise cross-platform solutions that seem to exist only on SEO-optimized listicles of cross-platform solutions such as Codename One, RhoMobile, Kony, Framework7, - e.g. https://www.way2smile.ae/blog/cross-platform-mobile-app-deve... (Again, what companies are actually building apps with these things?)
So Progress actually handed over development to a company called nStudio relatively recently. The proof/PR announcement feels like it's been wiped off the internet but there are traces still[0].
They've been great stewards so far -- improving the codebase and going after long-standing pain points, but it's worth mentioning.
[0]: https://www.reddit.com/r/nativescript/comments/gv968e/progre...
They've been great stewards so far -- improving the codebase and going after long-standing pain points, but it's worth mentioning.
[0]: https://www.reddit.com/r/nativescript/comments/gv968e/progre...
Hm, CodenameOne is actually something I was planning on making use of at some point in the future. I’m (solo) working on a Swing app that I want to bring to mobile, so it seemed like a good fit to convert to it or write a branch that used it. Is it actually a dumpster fire to be wary of?
Not that I know of, it just seems like one of those frameworks that exists and there is some online chatter mentioning it but I have no idea who actually uses it. If it turns out to be good you should let people about it!
I'm biased but it's pretty good and actually has a community behind it.
That's interesting to hear- where's the online community for Codename One located? I did find some Udemy courses for it, so there's that.
https://groups.google.com/g/codenameone-discussions
https://stackoverflow.com/tags/codenameone
and the github project. It isn't huge but it's been going on for nearly a decade with the same people.
Good to know, thanks! I’ll have to check out the links to the community when I get a chance too. Always good to know that a piece of tech you’d planned on using is healthy.
The one thing I wonder, can you explain why the Vue wrapper around React Native (https://github.com/GeekyAnts/vue-native-core/stargazers) seems to be more popular than Vue NativeScript (https://github.com/nativescript-vue/nativescript-vue/stargaz...)? I’m confused by why Vue developers of all people would use a Facebook/React stack for native development, so I assumed there had to be some advantage to using React Native.
My guess would be
> Seamless interop with React Native. Use core React Native components with Vue.js syntax out of the box
> Seamless interop with React Native. Use core React Native components with Vue.js syntax out of the box
We used Nativescript in production, and it is unending train wreck.
I advise everybody to avoid Nativescript for as long they self-qualify their project as anything serious.
The ecosystem, and upstream looks really much like the Wordpress plugin world, and is grossly unprofessional.
On the technical side, you will be always struggling with OOM, I/O performance, and the fact that you will be spending MORE time on native code for both Android, and Ios than if you did them separately.
I advise everybody to avoid Nativescript for as long they self-qualify their project as anything serious.
The ecosystem, and upstream looks really much like the Wordpress plugin world, and is grossly unprofessional.
On the technical side, you will be always struggling with OOM, I/O performance, and the fact that you will be spending MORE time on native code for both Android, and Ios than if you did them separately.
Would you mind expanding on the OOM and I/O performance issues you ran into? The ecosystem being less than enterprise-grade was known to me, but I did not run into any OOM or I/O performance issues.
Also, did you try either Flutter or React Native afterwards or go straight to native? Did you find them better?
Also, did you try either Flutter or React Native afterwards or go straight to native? Did you find them better?
Flutter provides an amazing developer experience. Dart is a great and modern programming language and built specifically for the needs of this framework. Everything just works out of the box. It's backed by google, it's completely open source, it doesn't need any native dependencies. It's a better version of Qt,RN, NS
Typescript fits my sensibilities and desire for expressive type-systems much more than Dart.
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).
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).
> OOM and I/O performance issues you ran into?
Sure, very simple react and vue apps regularly run into memory leaks upon navigating views, with most memory being leaked in UI part managed by nativescript, and not in the JS logic. NS does not do it's job freeing memory from UI.
The natural JS leakiness gets amplified if a leaked part references any JS 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.
> Also, did you try either Flutter or React Native afterwards or go straight to native? Did you find them better?
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.
RN also shares the same Java-JS interop issues as NS.
Sure, very simple react and vue apps regularly run into memory leaks upon navigating views, with most memory being leaked in UI part managed by nativescript, and not in the JS logic. NS does not do it's job freeing memory from UI.
The natural JS leakiness gets amplified if a leaked part references any JS 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.
> Also, did you try either Flutter or React Native afterwards or go straight to native? Did you find them better?
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.
RN also shares the same Java-JS interop issues as NS.
Thanks for explaining more, appreciate it and hopefully others will find this as useful as I did.
> 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...
> 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...
> The natural JS leakiness gets amplified if a leaked part references any JS object.
* The natural JS leakiness gets amplified if a leaked part references any Java object.
* The natural JS leakiness gets amplified if a leaked part references any Java object.
What kind of app was it?
I'm not sure about the current state of affairs but a few years ago Ionic used to be a default choice for cross-platform apps among Angular devs. And Angular itself was probably more popular then React in corporate world back then.
Great UI has diminishing returns that, for most orgs, are not worth the talent and effort it takes to create them. For that reason investment in these frameworks, or new frameworks at all, is discouraged. Web based approaches have completely supplanted native || crossplatform frameworks because its good enough and established enough to diminish the many development liabilities that other frameworks pose.
Not everyone is trying to display a widget, with data from a remote database. If you work with local/edge data, then having access to numpy/pandas/scikit-learn/pytorch can be quite handy
But the point of cross-platform frameworks is for non-tech or non-mobile focused companies to quickly churn out LOB apps with whatever developers they have on hand. (There was even one for PHP - KikApp - which appears to be dead.) So in theory, ignoring great UI/UX in favor of quick development time would drive investment in and adoption of some of these frameworks.
Your point on web based approaches also doesn't seem to match reality yet as PWA are still the once and future destiny of mobile apps, much like \(currentYear) is the year of Linux on the desktop. afaik, it would seem like most mobile apps are still primarily native, and if crossplatform, possibly React Native or Xamarin, with some older ones using Cordova/PhoneGap/Titanium. Web based approaches are far from replacing native and cross-platform; most companies that support mobile web also have their own apps.
Your point on web based approaches also doesn't seem to match reality yet as PWA are still the once and future destiny of mobile apps, much like \(currentYear) is the year of Linux on the desktop. afaik, it would seem like most mobile apps are still primarily native, and if crossplatform, possibly React Native or Xamarin, with some older ones using Cordova/PhoneGap/Titanium. Web based approaches are far from replacing native and cross-platform; most companies that support mobile web also have their own apps.
> The question is, who actually uses these projects? The people developing them? Hobbyists? Language diehards?
This is an interesting question, and one that (as Kivy developers) we wonder about ourselves. Others may have different perspectives, but mine is:
* Kivy is very much community built and community driven, it has no serious financial backing (though we are grateful for the donations we do get!) and a fairly small developer pool.
* Most of the commercial use of Kivy that I'm aware of is small companies using it for specific reasons that happen to make sense for them, usually involving some technical reason such as the combination of Python and a flexible drawing toolkit fitting both their dev interests and product requirements. I don't think there is a lot of commercial use, but e.g. one of the Kivy founders has been using Kivy commercially for many years in a variety of interesting projects.
* Kivy is not mobile-only or even mobile-focused, and the commercial usage reflects that. This is worth noting because people often think it was invented for mobile: it wasn't, it was invented to be very flexible, and this happened to make it mobile-ready.
* Most use of Kivy is probably from Python hobbyists, and may well be more weighted towards mobile since that's the most obvious standout feature as a Python gui toolkit (although not the only one).
I've been involved with Kivy for a long time, but never commercially - I got into it for fun while looking to make an app and strugging with an android development tutorial (turns out the instructions were just wrong for Linux...), and stayed with it for also fun. I'm most interested in the general principle that app development ought to be simple and easy for a wide range of tasks, and that in pursuit of this goal it does not have to be perfect. I like the idea that e.g. someone who has programmed a simple game or visualisation should be able to easily share it with their friends, on any platform including mobile. This is just my perspective of course, others do use it for other things.
I have a couple of my own apps that I think emphasise this perspective. Lazy Baduk (https://play.google.com/store/apps/details?id=net.inclem.laz...) is a Go analysis tool that bundles a superhuman AI: I threw it together in a weekend using some existing Python code I had lying around, because there was no Android app currently supporting the functionality I wanted. If I couldn't do that with Python, the app simply wouldn't exist. ColourBlind (https://play.google.com/store/apps/details?id=net.inclem.col...) runs the camera feed through a basic colour blindness simulation filter, I made this one just because I wanted to see what it was like and all the existing apps I could find were rubbish (in my opinion!). Even with the limitations of Python, I like mine much better than them.
This is an interesting question, and one that (as Kivy developers) we wonder about ourselves. Others may have different perspectives, but mine is:
* Kivy is very much community built and community driven, it has no serious financial backing (though we are grateful for the donations we do get!) and a fairly small developer pool.
* Most of the commercial use of Kivy that I'm aware of is small companies using it for specific reasons that happen to make sense for them, usually involving some technical reason such as the combination of Python and a flexible drawing toolkit fitting both their dev interests and product requirements. I don't think there is a lot of commercial use, but e.g. one of the Kivy founders has been using Kivy commercially for many years in a variety of interesting projects.
* Kivy is not mobile-only or even mobile-focused, and the commercial usage reflects that. This is worth noting because people often think it was invented for mobile: it wasn't, it was invented to be very flexible, and this happened to make it mobile-ready.
* Most use of Kivy is probably from Python hobbyists, and may well be more weighted towards mobile since that's the most obvious standout feature as a Python gui toolkit (although not the only one).
I've been involved with Kivy for a long time, but never commercially - I got into it for fun while looking to make an app and strugging with an android development tutorial (turns out the instructions were just wrong for Linux...), and stayed with it for also fun. I'm most interested in the general principle that app development ought to be simple and easy for a wide range of tasks, and that in pursuit of this goal it does not have to be perfect. I like the idea that e.g. someone who has programmed a simple game or visualisation should be able to easily share it with their friends, on any platform including mobile. This is just my perspective of course, others do use it for other things.
I have a couple of my own apps that I think emphasise this perspective. Lazy Baduk (https://play.google.com/store/apps/details?id=net.inclem.laz...) is a Go analysis tool that bundles a superhuman AI: I threw it together in a weekend using some existing Python code I had lying around, because there was no Android app currently supporting the functionality I wanted. If I couldn't do that with Python, the app simply wouldn't exist. ColourBlind (https://play.google.com/store/apps/details?id=net.inclem.col...) runs the camera feed through a basic colour blindness simulation filter, I made this one just because I wanted to see what it was like and all the existing apps I could find were rubbish (in my opinion!). Even with the limitations of Python, I like mine much better than them.
Very comprehensive answer, thank you! I'm glad to hear that Kivy has larger aspirations than simply being a mobile focused cross-platform solution, and that it's got enough of a community to sustain its efforts. Cool also that it's able to leverage Python tools that the native mobile apps aren't able to hook into. It sounds like Kivy does have a small community of avid Pythonistas.
I'm a hobbyist and I've been looking into these kinds of projects for a while. From my (limited) experience, the easiest way to go for a lot of cases is just to use a cross-platform game engine's UI capabilities, but there's some other interesting not-well-known stuff like HaxeUI and LambdaNative.
> use a cross-platform game engine's UI capabilities
Have you seen any examples, either production apps or tutorials doing so? Ironically, I've considered building a heavily menu-driven game in Flutter rather than using Unity, and seen an example of such:
https://www.reddit.com/r/FlutterDev/comments/iit6cf/i_made_a...
Have you seen any examples, either production apps or tutorials doing so? Ironically, I've considered building a heavily menu-driven game in Flutter rather than using Unity, and seen an example of such:
https://www.reddit.com/r/FlutterDev/comments/iit6cf/i_made_a...
I have an app, metro.drone [1], on the App and Google Play stores that I created with LÖVE2D. While I haven’t seen many other examples, I’ve seen a lot more cross-platform game engines than UI-explicit engines, many of which have (at least limited) GUI capability. I’m relatively new to programming so part of what attracted me to LÖVE2D instead of something else was the simplicity and modularity; LÖVE2D-compatible packages existed for exactly what I needed with metro.drone. I’ve come to the broad conclusion that it’s more about choosing the right ecosystem for a project than the right ui toolkit; I was originally going to use Elm but it didn’t have a good synth library.
I should again recap that I’m a novice programmer, so this should be considered more a description of my thought process than advice. :)
[1]: http://dmitrivolkov.com/projects/metro.drone
I should again recap that I’m a novice programmer, so this should be considered more a description of my thought process than advice. :)
[1]: http://dmitrivolkov.com/projects/metro.drone
I've been using Kivy for internal business programs for 2 years. There are some quirks and limitations, but IMO no more than you get with any other mobile stack. The big differences are that it bundles python packages with it, meaning you have access to hundreds of thousands of libraries via pip, and the design and iteration time are ridiculously low.
The downsides of Kivy are also the downsides of python; there is almost no design enforcement, no typing; if you want to do something stupid and dangerous, you're free to do so with no warnings, and you may not know it's stupid and dangerous. These are usually made up for by the large amount of time you'll have for testing, since you won't spend all the time you normally would fighting the IDE, toolchain, compiler, etc.
The part I like most about Kivy is that it's cross platform, android, ios, windows, Linux, mac, with almost no changes other than OS semantics like paths. I've built 5 large projects this year with it, mostly for custom CNC and motion control applications.
The downsides of Kivy are also the downsides of python; there is almost no design enforcement, no typing; if you want to do something stupid and dangerous, you're free to do so with no warnings, and you may not know it's stupid and dangerous. These are usually made up for by the large amount of time you'll have for testing, since you won't spend all the time you normally would fighting the IDE, toolchain, compiler, etc.
The part I like most about Kivy is that it's cross platform, android, ios, windows, Linux, mac, with almost no changes other than OS semantics like paths. I've built 5 large projects this year with it, mostly for custom CNC and motion control applications.
Ever since I discovered Kivy in 2013, it has had a special place in my heart, and because I know my way around it, I've used it for many smaller projects, and one non-trivial game project WIP: https://www.youtube.com/watch?v=m06AH7MN0i4
Graphically, my game is mostly straight-forward, but being a strategy game, the complexity is behind the curtains in the AI, pathfinding and other game mechanics. I am very thankful to continue using my mastery of Python in this endeavor, and even though it doesn't provide game development conveniences out of the box (so it took time to get started, compared to say, Godot), it allowed me to utilize - and build on - my experience in the language. Doing this allows me to control the learning curve, especially when it comes to learning about OpenGL, and how graphics work underneath in general.
Don't get me wrong, depending on what you're looking to do, Kivy can have a stronger learning curve in itself, especially if you're doing this sort of thing for the first time (app development, specifically, but of course game development too). It took me until around 2016 - after playing with Kivy on and off - to become completely comfortable with all of its concepts. Aside from learning to profile and troubleshoot some graphics performance issues (largely my own fault, in my implementation), Kivy has been reliable and, like a well-designed door, I rarely consciously note that I am using it!
Outside of games, as I mentioned, I have also used Kivy for internal tools professionally. One was for (visually, analog curves) creating simulated plastic injection molding sensor signals, in order to create and provide data sets for QA Automation. The other was for a specialized AV company's (internal) usage as a job/bid/information management app. Another project required the ability to flip, pan and zoom images for a 3d mirror viewer hardware set. And, here in 2020 I used it to train non-automation non-coding QA personnel into making their own mobile apps, learn about event handling, and to get a glimpse into what a developer might be considering or thinking as they build software.
I've always been bewildered at why Kivy doesn't (seem to) garner more public attention. For what it aims to provide, it hits the mark quite well. I enjoy using Python the most, so I prefer to use it for most of my work, personal and professional. In that way, Kivy has allowed me to progress towards mastery of Python, without having to spend that effort on other tech stacks. (Having said that, I have experience outside of Python, just to be clear, it's not out of necessity.) As others I'm sure, I have a life outside of my job and side game project, so I have intentionally chosen what to invest my time in learning.
This turned into a bit of a ramble. Anyway. For me, it's a great fit, and I'm thankful that it exists, and people continue to build and refine it. I get to keep writing Python, and use it in more ways and places because Kivy exists.
Graphically, my game is mostly straight-forward, but being a strategy game, the complexity is behind the curtains in the AI, pathfinding and other game mechanics. I am very thankful to continue using my mastery of Python in this endeavor, and even though it doesn't provide game development conveniences out of the box (so it took time to get started, compared to say, Godot), it allowed me to utilize - and build on - my experience in the language. Doing this allows me to control the learning curve, especially when it comes to learning about OpenGL, and how graphics work underneath in general.
Don't get me wrong, depending on what you're looking to do, Kivy can have a stronger learning curve in itself, especially if you're doing this sort of thing for the first time (app development, specifically, but of course game development too). It took me until around 2016 - after playing with Kivy on and off - to become completely comfortable with all of its concepts. Aside from learning to profile and troubleshoot some graphics performance issues (largely my own fault, in my implementation), Kivy has been reliable and, like a well-designed door, I rarely consciously note that I am using it!
Outside of games, as I mentioned, I have also used Kivy for internal tools professionally. One was for (visually, analog curves) creating simulated plastic injection molding sensor signals, in order to create and provide data sets for QA Automation. The other was for a specialized AV company's (internal) usage as a job/bid/information management app. Another project required the ability to flip, pan and zoom images for a 3d mirror viewer hardware set. And, here in 2020 I used it to train non-automation non-coding QA personnel into making their own mobile apps, learn about event handling, and to get a glimpse into what a developer might be considering or thinking as they build software.
I've always been bewildered at why Kivy doesn't (seem to) garner more public attention. For what it aims to provide, it hits the mark quite well. I enjoy using Python the most, so I prefer to use it for most of my work, personal and professional. In that way, Kivy has allowed me to progress towards mastery of Python, without having to spend that effort on other tech stacks. (Having said that, I have experience outside of Python, just to be clear, it's not out of necessity.) As others I'm sure, I have a life outside of my job and side game project, so I have intentionally chosen what to invest my time in learning.
This turned into a bit of a ramble. Anyway. For me, it's a great fit, and I'm thankful that it exists, and people continue to build and refine it. I get to keep writing Python, and use it in more ways and places because Kivy exists.
I use it for a hobby project: a weather station running on raspberry pi and touch screen. Allows me to write it in python, and display charts and metrics without running the entire X11 stack.
Seemed like the simplest and most productive stack to build something like this. Has good support for postgres to get the data efficiently, charting and touch input.
Seemed like the simplest and most productive stack to build something like this. Has good support for postgres to get the data efficiently, charting and touch input.
Kivy is used in the embedded world, for example by the ECR-1 and GR-1 synthesizers:
https://www.tastychips.nl/
Kivy has been around for a surprisingly long time and has been fairly widely used in industrial software. I used to work for a company that made kivy-based automation software.
Kivy is awesome considering what it,s trying to do. As ambitious as flutter but without corporate support. Unfortunately the project is quite under-resourced, can anyone help?
For example, stick to the basics and it works well. But do something off the beaten track like write a background service for Android and hit a bug and you're completely on your own, even if you offer to pay a core dev. I once hit another bug where Unicode couldn't be used in .kv files, was a one line fix but there were 70 unread pull requests and more even more issues untouched. Two or three heros try to help on the mailing list. I gave up but would like to try one more time with 2.0.
For example, stick to the basics and it works well. But do something off the beaten track like write a background service for Android and hit a bug and you're completely on your own, even if you offer to pay a core dev. I once hit another bug where Unicode couldn't be used in .kv files, was a one line fix but there were 70 unread pull requests and more even more issues untouched. Two or three heros try to help on the mailing list. I gave up but would like to try one more time with 2.0.
What problems did you have with android services? Have been using them without issues (sticky services work well enough), and with python machine learning/scikit-learn, scipy,numpy, pandas, opencv this framework is one of a kind for rapid moibile development if you are doing any kind of edge data processing.
1) I have toyed with Kivy, but found it not easy to use. It was a few years ago.
2) I prefer tkinter, a python wrapper for tk.
3) In regards to whether or not anyone still needs this, consider that tkinter search traffic bottomed out in June 2012, and has been rising ever since: https://trends.google.com/trends/explore?date=all&geo=US&q=t...
2) I prefer tkinter, a python wrapper for tk.
3) In regards to whether or not anyone still needs this, consider that tkinter search traffic bottomed out in June 2012, and has been rising ever since: https://trends.google.com/trends/explore?date=all&geo=US&q=t...
Long time fan of kivy checking in here. Important if you wanna be off internet grid. Portal to OpenGL as well. Kivy hugely underrated and better than QT imho. Made a 2D skateboarding game and tried to get it working with buildozer on android back in the day (2017) Cheers to the devs.
I really like the Kivy project's goals and the demos I saw were super fast and nice. But when I had a look at actually building something with it I discovered that the default UI is completely raster based, which is just a weird deal breaker.
If there was one thing I could wish to be revamped about Kivy it's the default widgets. There's a core of good ones, especially those that are most commonly used, but quite a few make bad design decisions like an over-reliance on images for styling. This is often much easier to work around than is probably obvious and maybe that's part of the problem, more experienced developers likely habitually sidestep the parts that don't work well. But on the other hand, it's quite a bit of work to revamp them (including documentation and dealing somehow with breaking changes it would introduce), unfortunately that has kept us from seriously addressing it so far.
How does Kivy compare to Sciter?
I love the idea of Kivy, an open-source, community-driven, cross-platform framework, but flutter delivers much nicer mobile apps, and QT a far better desktop apps. I do not think that I have ever used a cross-platform app that works as well on desktop as on mobile.
If anyone's used Kivy or Beeware for mobile app development, I'd love to hear about it.
A cross-platform framework which does not support the web platform. What's the point?
There are so many UI development frameworks, and so many of them are missing the web.
This limits the options available enormously, and is forcing programmers into inconvenient and inappropriate solutions.
Hey! I actually did my thesis on porting kivy to the Web and may I tell you, its going to be infinitely easier and faster to just develop your app for Web or hire a good webdev right now.
Nativescript angular can run both Web and native from 1 codebase if you like, but kivy is inherently hard to port
Nativescript angular can run both Web and native from 1 codebase if you like, but kivy is inherently hard to port
So, I’m not sure whether the website was made using the product, but the homepage renders overlapping text on Chrome for IPhone 11 with IOS 14
As has already been said, Kivy isn't a web framework, but we're well aware the website isn't great. Unfortunately it hasn't had much love for a long time, especially as it's quite a task to seriously change it and we're both under-resourced and Python-oriented. We've been talking about various options for a long time. It's possible we might make some moves now as Kivy 2.0 was just recently released, which was a major update taking up a lot of focus.
From a marketing protective it may have made sense to revamp the website before launching 2.0 since you could've made a lot of better first impressions.
That said I don't think it's that bad, but the styling could be nicer.
That said I don't think it's that bad, but the styling could be nicer.
Thanks for clarifying. Good to understand I’ll take a closer look at Kivy 2.0.
Kivy is not a web framework, it's a library for making native desktop (or etc.) applications.
The question is, who actually uses these projects? The people developing them? Hobbyists? Language diehards? If you're a large company that just needs LOB apps, one would assume one of the aforementioned projects (or Delphi) would be sufficient. Who uses NativeScript, Ionic, QT on mobile, or obscure stuff like Sencha, Alibaba's Weex or Codename One?
RubyMotion at least has one famous app:
http://www.rubymotion.com/news/2014/04/08/rubymotion-success...