Live data from Hacker News

SwiftUI

developer.apple.com

301–310 of 394 posts

Re: SwiftUI

#301

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…

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

#302
post #26

I'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…

Google announced jetpack compose in last i/o. But it seems like it was not discussed here at all. And from other comments seems like developers don't know about it.

Re: SwiftUI

#303

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…

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

Fascinating! (And on reflection, Blender probably does something similar, since it's super modular and practically every field is in perfect sync with the view and the data.)

Re: SwiftUI

#304
OMG, has anyone noticed the device icons on the bottom of the SwiftUI page? Steve will be turning in his grave...

Re: SwiftUI

#305
post #91

I’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…

> 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.

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

#306

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…

I disagree. I'd argue React is most useful when doing something highly interactive.

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

#307
post #238
post #200

Earlier 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…

That after-the-fact reasoning link that gets posted every time someone questions Dart is well known, no need to give it to me.

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

#308

One 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…

I feel you. I understand that Apple tries to cater to the "web developer" crowd as well, but sometimes this feels like a regression compared to what OPENSTEP was about.

Re: SwiftUI

#309

I'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.

Some other fellow developers are happy to target just Windows, just PS4, just XBox, just Wii, just Switch, just Android, just Arm mbed, just Tizen, just whatever OS.

Not everyone has this urge to create FOSS software, available as free beer in every possible OS out there.

Re: SwiftUI

#310

I’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!

Is an imperative API available as well?
Post reply on HN