Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would need explicit state and imperative co…
SwiftUI
301–310 of 394 posts
Re: SwiftUI
#302I'd be curious to know how many React Native devs work on cross-platform apps. In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN. Given that SwiftUI has live reloading and a sensible template interface I could absolutely see it winning over some RN devs. There's something to be said (particularly with Apple) for using the native toolset rather than RN, Flu…
Re: SwiftUI
#303Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would need explicit state and imperative co…
Adobe uses a declarative UI system, and what they call a 'property model', which apparently successfully reduced their UI code by a factor of over 500. The system is available here: https://stlab.adobe.com/group__asl__overview.html
Re: SwiftUI
#304Re: SwiftUI
#305I’m one of the engineers that spearheaded this initiative inside of Apple. I just wanted to thank the HN community—I’ve been reading HN for 10 years now and it’s been formative in my development as a software engineer. If you’re at WWDC stop by the labs and say hi!
I just wanted to say thank you - I'm a web developer who has been learning iOS dev in his spare time and made the decision pretty early on to build my views programmatically. It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically. Also, the code for building UIs programmatically ha…
Well you know, Cocoa and its predecessor OPENSTEP were built on the idea of using IB to compose interfaces out of actual objects that then got "freezed" into a file. So, no code at all, that was the idea.
Building views programmatically was the old school way even back then. ;)
Re: SwiftUI
#306Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would need explicit state and imperative co…
There's nothing stopping you from writing imperative, side-effect heavy code. But it's something you deliberately opt into, usually on the edges of the program, rather than something you have to deal with by default. Absolutely nothing about React discourages this.
Re: SwiftUI
#307Earlier quoted context omitted.
I know pretty much what he/she meant, was just making a point that I don't believe in Flutter's long term success. Trying to sell Dart a 2nd time was a mistake.
Flutter's not a PR campaign for Dart, they're a separate project that chose Dart based on its technical capabilities [1]. Given Flutter enables the nicest native x-plat dev experience today I'd say it has a very bright future, which they've also recently announced Flutter for Desktop and Embedded devices. Jetpack compose is years away from the same kind of x-plat support that Flutter's providing for Mobile, Web, Desk…
Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities".
Flutter is a way to rescue Dart, plain and simple.
Yes, Jetpack Compose might be doing its baby steps, but I am betting most developers are more keen in having Kotlin than Dart on their CV, specially after Dart v 1.0's demise.
And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.
Re: SwiftUI
#308One more blow to the head for objective-c. Wonder if this the final nail in the coffin.
Given that Craig Federighi basically said this type of migration only comes around every 20 years, I would imagine Objective-C is dead. I do hope they actually take the time and fix the Swift examples so they are updated. This does hurt. I've been programming Objective-C since NeXTSTEP and love it. Swift is still like Perl for me. Something I will use for programming for money, but not enjoy for one minute. I loved t…
Re: SwiftUI
#309I'm sure SwiftUI has been in development for a long time, but it seems to me to be Apple's response to frameworks like React Native and Electron. We get a simple way to make UIs for multiple platforms, we get a nice batteries-included language, and Swift 5.1's dynamic method offers a similar functionality to hot reloading. Of course, it can't answer everybody's needs (no Windows, Linux, or Android support) but combin…
>Of course, it can't answer everybody's needs (no Windows, Linux, or Android support) I don't understand how my fellow developers could ever tolerate Apple doing this. This goes one way, and its been like this for decades.
Not everyone has this urge to create FOSS software, available as free beer in every possible OS out there.
Re: SwiftUI
#310I’m one of the engineers that spearheaded this initiative inside of Apple. I just wanted to thank the HN community—I’ve been reading HN for 10 years now and it’s been formative in my development as a software engineer. If you’re at WWDC stop by the labs and say hi!