Live data from Hacker News

SwiftUI Defaults Considered Harmful

tonsky.me

101–110 of 135 posts

Re: SwiftUI Defaults Considered Harmful

#101
post #51

Just when I thought Lisp had been ransacked for every last feature that language designers were willing to steal, the "War on commas" pops up -- complete with discussion of the essential differences might exist between "(" and "{", the pain of needing another way to say "if", and the lack of support for the rest of the language. And the last couple interesting Swift libraries I saw had .gyb files and #if directives.…

many modern languages have macros: rust, crystal, elixir, nim not very corporate though, but getting there? with rust(mozilla a bit and others)

Java and .NET languages also have them, although a bit cumbersome via attributes, compiler plugins and on .NET's case, expression trees.

Re: SwiftUI Defaults Considered Harmful

#102
post #69

I really don't think this is a good criticism of SwiftUI. The author is confused about the whole approach to SwiftUI and spends a lot of words complaining about issues arising out of that confusion. E.g., SwiftUI doesn't use Swift's DSL capability to avoid commas. It uses it to have a declarative DSL integrated into Swift programs. You could argue about the entire approach, but instead the author complains about comm…

The author is also the author of Clojure/script libraries Rum snd Datascript. He knows what declarative means very well.

Swift UI creates a mess of special cases pretending to be declarative, and does a poor job of it.

Re: SwiftUI Defaults Considered Harmful

#103

Earlier quoted context omitted.

JSX is 'just' an XML-like syntactic sugar for making nesting function calls nicer in Javascript. Yes, its a DSL, but it keeps the "domain" extremely small and it transpiles in a very straightforward way down plain javascript madeofpalk // is syntactic sugar for React.createElement(Container, null, React.createElement(Text, { weight: "bold" }, "madeofpalk"), React.createElement(Image, { src: profilePic }) ); Whenever…

I guess I'm not sure why this is better than the Kotlin/Tornado/SwiftUI approach of allowing you to move a lambda in the last parameter visually out of the function. So: container { text(weight = "bold") { "madeofpalk" } image(src = profilePic) } It seems more logical and consistent with the rest of the language. The only reason for the HTML-like syntax is JavaScript's tight connection to the web, after all.

I apologise for not being clear, but the point I'm trying to make is not around the angle bracket syntax, but with how light the DSL is and for any sort of logic syntax, you just escape back to Javascript.

JSX does not have conditionals or loops in its syntax. SwiftUI does.

Re: SwiftUI Defaults Considered Harmful

#104

Earlier quoted context omitted.

Yeah, I did think it was amusing reading that on my 27" 2550px wide monitor monitor that the site formatted it so narrowly. https://i.imgur.com/VG31Kpj.png

For body copy that line length is pretty much ideal (for readability), but the code blocks could definitely benefit from being as wide as possible...

Yeah, the reading experience was pretty comfortable. Just thought it was amusing that the author hoped I had a big monitor when the author constrains the code blocks to such a narrow width.

Re: SwiftUI Defaults Considered Harmful

#105

I was really excited about SwiftUI after having done a lot of React development recently. The declarative style is so much nicer than the MVC/procedural code that regular UIKit code becomes. After 30 minutes of updating Xcode I was able to start writing SwiftUI code. Then another 2 hours upgrading our Swift project to the latest version of Swift. I googled for documentation, found barely anything and the code samples…

> ... after having done a lot of React development recently ... All this prompted me to finally give react-native a try. In under 15 minutes I had a working example. The fact that you, a React developer with lots of experience with React were able to come up to speed vastly quicker on React Native shouldn't be surprising, that's a feature of the platform. You are the exact sort of person React Native was designed to…

Sorry if it wasn't clear enough. I'm by no means a React-developer with lots of React experience. I'd say I have more iOS-development experience than React. The app I wanted to port is already fully written in Swift. I've written and launched a couple of apps in Swift over the years, and also a couple of apps in Objective-c.

Re: SwiftUI Defaults Considered Harmful

#106
post #70

I was really excited about SwiftUI after having done a lot of React development recently. The declarative style is so much nicer than the MVC/procedural code that regular UIKit code becomes. After 30 minutes of updating Xcode I was able to start writing SwiftUI code. Then another 2 hours upgrading our Swift project to the latest version of Swift. I googled for documentation, found barely anything and the code samples…

”after having done a lot of React development recently […] All this prompted me to finally give react-native a try. In under 15 minutes I had a working example“ I agree SwiftUI is poorly documented and (from what others say), probably, not quite production ready, but I also guess that comparison is a bit unfair. Or are react and react-native completely different beasts?

I'm not a die-hard follower of Apple developer news, but it being released in June 2019 made it feel at least somewhat mature to try out. There's nothing AFAICS on the SwiftUI documention mentioning that it's not quite production ready.

> Or are react and react-native completely different beasts?

The language is the same, and the core concepts are the same, but the SDK's are completely different. You are using different build tools, different API's, different platforms. It's not HTML-in-JS. So a React developer is not going to be fluent in react-native by default.

Re: SwiftUI Defaults Considered Harmful

#107
post #79

I was really excited about SwiftUI after having done a lot of React development recently. The declarative style is so much nicer than the MVC/procedural code that regular UIKit code becomes. After 30 minutes of updating Xcode I was able to start writing SwiftUI code. Then another 2 hours upgrading our Swift project to the latest version of Swift. I googled for documentation, found barely anything and the code samples…

> Oh and recompiling took a minimum of 30 seconds each time. For a simple hello world SwiftUI app? I just checked a project I had open in xcode and it recompiled in under 1s. Thats on a mid range 2013 MBP. > After making a change I saved the file, alt-tabbed to the simulator and the changes were already applied. I guess Apple is aiming to get something like this experience through previews, which are a little broken…

Sorry if I wasn't being clear. We have an iOS app and my plan was to try out migrating an existing Viewcontroller to SwiftUI (the login screen).

Re: SwiftUI Defaults Considered Harmful

#108
post #69

I really don't think this is a good criticism of SwiftUI. The author is confused about the whole approach to SwiftUI and spends a lot of words complaining about issues arising out of that confusion. E.g., SwiftUI doesn't use Swift's DSL capability to avoid commas. It uses it to have a declarative DSL integrated into Swift programs. You could argue about the entire approach, but instead the author complains about comm…

The author is also the author of Clojure/script libraries Rum snd Datascript. He knows what declarative means very well. Swift UI creates a mess of special cases pretending to be declarative, and does a poor job of it.

He's suggesting he ought to be able to use imperative Swift control flow constructs in the declarative SwiftUI DSL. I suppose I can't really know exactly what his confusion is, but that just doesn't make sense.

Re: SwiftUI Defaults Considered Harmful

#109

Earlier quoted context omitted.

Aw..heck. I'm not gonna get into back-and-forth. I will say that I have been developing Apple software for 34 years, so I tend to be a little on the.."hard-boiled cynic" side. I have taken OpenDoc and QuickDraw GX classes, because they were "The Next Big Thing." I also busted my butt, making sure that my apps were "Copeland-ready" (Darn it, now I have to do fifty push-ups) . I've learned that it's a good idea to stan…

Leaning towards the careful end of the spectrum, I can respect that. Especially once you're fast with UIKit, and Auto Layout. And Auto Layout kinda proves your last point; there's absolutely nothing "auto" about it.

Auto Layout is a nightmare. I won't be sad to see the back of it.

It took me a couple of years to figure out how to use it properly.

Like I said, we're on the right track, and I doubt that Apple will let this fall by the wayside. I think they were planning this at about the same time that they started dreaming up Swift.

Re: SwiftUI Defaults Considered Harmful

#110

I was really excited about SwiftUI after having done a lot of React development recently. The declarative style is so much nicer than the MVC/procedural code that regular UIKit code becomes. After 30 minutes of updating Xcode I was able to start writing SwiftUI code. Then another 2 hours upgrading our Swift project to the latest version of Swift. I googled for documentation, found barely anything and the code samples…

I’m a 10 years ios developer, and i also gave up tryin to write a small app in swiftui after having tried for an hour. It’s just impossible with the current level of documentation.

I think the picture is darker than what you’re describing : as long as apple doesn’t provide a real cross-platform environment (like google does with flutter, or facebook with react) then it doesn’t really matter what they end up doing with swift UI.

My intuition is that they know it, and that they’re working on something pretty big in that field, maybe as an improved , cross-platform version of swift ui. That would explain the lack of documentation (why document something that’s only a temporary version of a tech). But maybe i’m dreaming and everybody at apple live in its own bubble...

Post reply on HN