SwiftUI • Hacker News Board

Re: SwiftUI

#211

Post by jcelerier » Mon, Jun 03, 2019, 10:22 PM UTC

untog wrote: post #67

jcelerier wrote: post #16

The syntax example is still not as clean as QML, which is already a ten-year-old language (examples: http://qmlbook.github.io/ch04-qmlstart/qmlstart.html ).

But it is Swift, which (at the risk of stating the obvious) QML is not. And you can't write an entire app in QML. There's something to be said for being able to use one language for all things.

> But it is Swift, which (at the risk of stating the obvious) QML is not.

sure, and I agree that Swift has some better features and a better foundantion than JS on which QML is based upon

> And you can't write an entire app in QML.

This however is not true. I've worked on multiple pure QML apps so far (well, if you don't count the auto-generated main.cpp). Remember that you have access to a complete ES7 JS engine which allows for a lot of stuff.

Re: SwiftUI

#212

Post by ng12 » Mon, Jun 03, 2019, 10:23 PM UTC

_bxg1 wrote: post #171

ng12 wrote: post #164

Earlier quoted context omitted.

What's the difference between a class and a function with local state? (Semantics aside, either way this behavior is implemented in React via useState or setState, MobX has nothing to do with it)

MobX takes normal data (usually class properties) and makes it observable, via an annotation. That very much appears to be what the @State annotation in the Swift code is doing, though I don't know for sure. setState is a totally special container for data; while it technically lives in a class member (this.state), it can only be modified via setState. It isn't observable, so much as setState just internally triggers…

@observable/useState/React.Component.state are all conceptually identical, just with varying implementations of the magic. All of them summon an observable value from the void and provide some method of updating said observable.

That said, @State seems most identical to useState -- it provides an observed value which you use $/.binding to update.

> It's very weird and funky because the whole point of non-class components is for them to be pure functions which have no state.

That's a false assumption, that's not the "point" of functional components. Functional components were always pure simply because there was no way to make them stateful. There are distinct benefits for using stateful functional components over classes -- mainly less boilerplate and abstractable/re-usable state functions.

Re: SwiftUI

#213

Post by [deleted] » Mon, Jun 03, 2019, 10:26 PM UTC

ardit33 wrote: post #179

Redoubts wrote: post #52

var body: some View { Wait, what? When was `some` a keyword?

I am still scratching my head why the 'some' keyword is needed/required for opaque types. Eg. SquareButton and RoundButton are implementations of the Button (protocol). You want to create a function that returns the button, but you don't want to specify to the user exactly what type of button is it (as it doesn't matter). Your function could just declare the top level protocol as the return type without needed to spe…

[deleted]

Re: SwiftUI

#214

Post by nicky0 » Mon, Jun 03, 2019, 10:28 PM UTC

skohan wrote: post #202

ardit33 wrote: post #179

Earlier quoted context omitted.

I am still scratching my head why the 'some' keyword is needed/required for opaque types. Eg. SquareButton and RoundButton are implementations of the Button (protocol). You want to create a function that returns the button, but you don't want to specify to the user exactly what type of button is it (as it doesn't matter). Your function could just declare the top level protocol as the return type without needed to spe…

The difference is subtle but it's there. The "some" keyword indicates that the function returns a specific type, even if that type isn't known to the caller. One place where this is meaningful is if you have to use the result of that function in a generic function. For instance if my functions are defined like this: func createPlayButton() -> Button { ... } func doSomething (_ button: T) { ... } And I try to call thi…

Why doesn't a protocol conform to itself?

Re: SwiftUI

#215

Post by jcelerier » Mon, Jun 03, 2019, 10:29 PM UTC

_fbpt wrote: post #93

jcelerier wrote: post #16

The syntax example is still not as clean as QML, which is already a ten-year-old language (examples: http://qmlbook.github.io/ch04-qmlstart/qmlstart.html ).

I think QML is used for Qt Quick and not compatible with desktop-style Qt Widgets. Qt Widgets .ui files are human-unreadable, and when edited in Qt Designer, usually lead to incorrect tab order (see LMMS's settings screen). All of these seem somewhat conceptually similar to Audacity ShuttleGUI ( https://wiki.audacityteam.org/wiki/ShuttleGui ) Or the Python context-manager-based declarative GUI (wrapping PyQt) I wrote…

> I think QML is used for Qt Quick and not compatible with desktop-style Qt Widgets.

yes, but it does not prevent you to make desktop apps with it. See e.g. Kirigami UI which is based on QtQuick : https://kde.org/products/kirigami/

(and for "large" desktop apps made with QtQuick, look at the Blizzard launcher, or Substance Designer which is as much a desktop app as one can aspire to be : https://cdn.studiodaily.com/wp-content/uploads/2019/05/subst... )

QML has a fundamental difference with the links you showed : it is able to create bindings according to variables used in expressions / functions / etc.

e.g. if you do

    MyWidget { 
         width: { if(y > 50) 
                    return f(height) + x;  
                  else 
                    return otherItem.height / height;
         }
    }

then whenever any of the properties used in the expression changes, the width is recomputed.

Re: SwiftUI

#216

Post by charrondev » Mon, Jun 03, 2019, 10:30 PM UTC

eugeniub wrote: post #207

dep_b wrote: post #153

Earlier quoted context omitted.

One thing that Google does right with Android is back porting to older versions.

I'm having a hard time figuring out how this statement can be even remotely accurate.

Whenever new frameworks or pieces of android come out, they are often accompanied by a compatibility library that you can ship in your app to use the new API and target older platform versions.

Re: SwiftUI

#217

Post by binthere » Mon, Jun 03, 2019, 10:31 PM UTC

zapzupnz wrote: post #166

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…

I wouldn't call anything close to cross-platform if it only works on Apple's products and devices.

Re: SwiftUI

#218

Post by grey-area » Mon, Jun 03, 2019, 10:31 PM UTC

AprilArcus wrote: post #204

grey-area wrote: post #136

Earlier quoted context omitted.

This must be the .. fifth entirely new UI framework from Apple? This isn't true at all. Since iOS launched there has been UIKit and then this SwiftUI. They didn't say anything about iOS. There have been lots of UI frameworks from Apple, some abandoned before they were even finished: QuickDraw, Quickdraw GX, HIToolbox, AppKit, Cocoa Touch/UIKit, Playgrounds/IB, SwiftUI The constantly changing frameworks and languages…

QuickDraw and Quickdraw GX aren't UI frameworks (like PowerPlant, AppKit or UIKit), and they aren't a widget library (like HIToolbox). They're much more lower-level than that; drawing libraries on the level of Quartz, Cairo, Skia, or GDI.

Ooh, that mention of PowerPlant that takes me back, I remember CodeWarrior too back in the day.

Yes you're right there are various levels here - sometimes it's hard to distinguish them. There have definitely been at least 5 UI toolkits though, and probably more, though of course over the life of Mac OS that is not terribly unexpected. For those who lived through the transition to OS X, this sort of churn is not unusual, and I do think it does benefit platform vendors - they have zero incentive to keep supporting their technologies over decades and every incentive to increase churn.

Quickdraw GX I remember particularly because there was such fan-fair about it as a replacement for all your graphical needs (such as drawing text), and yet it was dropped before it could even really be used (same with Quickdraw 3D). I can't remember what apple called their UI toolkit at the time, which was based on Quickdraw, then GX, but I don't think it was Carbon, that came later didn't it? I think I've found it now, was it MacApp?

Re: SwiftUI

#219

Post by binthere » Mon, Jun 03, 2019, 10:31 PM UTC

Will there be a similar API for Objective-C?

Re: SwiftUI

#220

Post by ehsankia » Mon, Jun 03, 2019, 10:33 PM UTC

Jerry2 wrote: post #38

oflannabhra wrote: post #23

This is fantastic, and I am almost upset by how little info the keynote address included. Obviously there will be a ton of detail coming out this week with the labs and documentation being released, looking forward to that. As an iOS developer, this is by far the biggest announcement. This has huge potential to provide value to me and my team. I'm looking forward to ripping out programmatic NSLayoutConstraint and Int…

The "real" developer keynote is "Platforms State of the Union" which will surely cover a lot more of it. The morning keynote is for the press and executives to highlight latest releases with some dev stuff thrown in.

Yeah, it's similar to I/O where there's a separate developer keynote, and specific "State of the Union" talks for each platform/framework.