-
-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Credit SwiftWebUI in a special way in README.md #140
Conversation
I didn't actually bring any code into Tokamak from SwiftWebUI, at least not intentionally. It's possible my brain wrote the code similarly in some places 😄 |
That's cool, thanks for clarifying. Hi @helje5, just letting you know that we didn't reuse any of your code explicitly, but just as @carson-katri I had a look at how things work in SwiftWebUI to reimplement them in Tokamak, but in a slightly different way due to the differences in the architecture. I hope that that attribution in |
I can't say whether I'm OK with that, I'd have to review your code (Samsung to Apple: "just letting you know that we didn't copy your iPhone" 🙄). If what you say is true, there should be no issue. I intentionally put the project up so that people can learn from it (I also gave it a proper license to avoid that people actually use it, which would be bad). What I find a little "weird" is that @carson-katri first asks me to change the license of SwiftWebUI so that you can use it, and then you come along with:
That's not cool either way 🙄 Also "not intentionally"? Please take care when using other people's code, I put quite some work into SwiftWebUI. Anyways, no hard feelings. Good luck with your project, looking forward to see SwiftUI in the Wasm browser! 🎉 |
@helje5 Thanks for clarifying, and I apologize it turned out to be this way. Would something like this work better?
This point would also be moved to the top of Acknowledgments list, or it could be featured more prominently in some other place if you'd prefer? We'd also add "ZeeZide GmbH" to Is there anything else we can do to mend matters? I look forward to hearing from you. |
@helje5 I am very sorry for how this happened. When I originally worked on the SwiftWebUI code I had no idea Tokamak even existed. When I asked about the license I had no intention to drop the project and start working on Tokamak. I will still be making changes to the SwiftWebUI fork, as it is more fleshed out than Tokamak. I would like to apologize again for my comment earlier in this thread. I in no way intended to belittle your contributions to the community and this project. My intention was to point out that I was not bringing over code directly from SwiftWebUI, as the internals of the two are very different, and anything similar would have been the API compatible with SwiftUI, which I did not copy but wrote using the swiftinterface file. I hope this clears some things up, and I again apologize. |
Hey, first of all I'd like to repeat that:
What you try to do is nice, I like it! Just be a little more careful w/ IP and stuff, it can easily break projects later on. Wrt the license, only you know what you did:
Wrt the acknowledgment. I like that you acknowledge my stuff (and I appreciate that this Issue was even opened, which shows that you care). No need to move me to the top or anything, I might do a PR for a little better wording. P.S.: The Tokamak name feels weird and is hard to remember (to/for me at least). Might not be too late to change it. |
I think I need to share a little bit of history here to clarify things on my side. The first commit to this project was made in September 2018, 9 months before SwiftUI was publicly announced. At that point it seemed clear to me that UIKit and AppKit couldn't be the future of UI development with Swift, so I started exploring a port of the React API to Swift. In my experience, React was a pretty good solution at that time and was adopted widely enough for people to be acquainted with the general idea. I also quite liked the architecture of React (except its use of JavaScript obviously), as it has a well-documented reconciler algorithm that works independently from platform-dependent renderers, which also allowed React Native to be developed. My plan was to build something similar to the React API in Swift with platform-specific renderers for macOS and iOS, and then potentially for WebAssembly, Android and Windows. The project was named Gluon back then, as I wanted to continue the atomic/nuclear physics theme of React's logo. After some time I discovered that the Gluon name was already adopted widely enough, especially in the cross-platform UI development context, but sticking with the nuclear physics theme I renamed it to Tokamak, which may sound weird to Western ears, but I got enough feedback from native English speakers that's a fine name. It also wasn't as widely adopted as a name in the software context (certainly not as widely as Gluon), and it seemed like using it made sense from the SEO perspective: unique enough to get surfaced in search engine results (keeping both Google and GitHub search engines in mind). Shortly after a short series of 0.1 releases with the React API, Tokamak for iOS/macOS was sherlocked by SwiftUI at WWDC 2019. It no longer made sense to continue developing it in that form for Apple's platforms, even though it could still be useful for other platforms. I still think that it's going to be hard to convince Swift developers to use something that doesn't look like SwiftUI, at least as long as the majority of Swift developers target Apple's platforms. Thus the only path forward with the project seemed to be ditching the React API and making Tokamak look more like SwiftUI. To be fair, the primary credit should got to all SwiftUI API designers, as it really is a nice API. While similar to React in spirit, thanks to property wrappers, function builders and even basic immutable value types support in Swift, SwiftUI is much more convenient to work with. At the same time, the React-inspired architecture of Tokamak could still be maintained to allow supporting multiple platforms, which I think is what we've been able to achieve so far. @helje5 releasing SwiftWebUI was an amazing milestone, showing that Swift and SwiftUI could be viable for browser apps. I considered contributing to SwiftWebUI, but its architecture was vastly different and couldn't be adapted for Tokamak, and reimplementing bits of SwiftUI from scratch seemed also to have some educational value for me. I personally didn't copy any code from SwiftWebUI, while I did have a look at it after the fact just to compare the approaches purely on technical merits. In the code that I wrote the similarities are coincidental stemming from the fact that we both tried to follow the actual SwiftUI API. But this is why I was asking @carson-katri about his code in the first place, knowing that he worked with the fork of SwiftWebUI adapted for WebAssembly. Now with regards to IP, we all should be aware that SwiftUI logo and name are trademarked and copyrighted. This is one of the reasons I don't want Tokamak to have anything related to SwiftUI in its name. I also don't want to pitch it as "SwiftUI for platform X" (WebAssembly/DOM at the moment, hopefully many other platforms in the future), it already had a different API in the past, and who knows how things turn out in the future with its SwiftUI API. And given that it already had to change the name once, you have to come up with really good alternative name not connected to SwiftUI to get it changed the second time, we all know that naming things is hard. 😄 Suggestions are obviously very welcome. The situation somewhat reminds me of how things have evolved with Xamarin/Mono and Microsoft. I'm happy that it's a good precedent and I hope we could arrive there at some point. On the other hand, the fact that Swift itself is patented worries me that this could be more similar to how the Google v. Oracle case went. And no, I don't believe the excuse that Swift was patented to defend from patent trolls, as almost any other programming language is not patented and no patent trolls whatsoever attacked their respective communities. Ironically, the lack of patents on C/C++ is what allowed Apple to develop and maintain LLVM and Clang. Obviously, there's no way that Tokamak becomes as big as Android Java API did, so most probably Apple will just continue to pretend that the need for cross-platform SwiftUI and all attempts to satisfy it don't exist. Which is not great, but not too terrible either. |
I know @carson-katri also worked on the SwiftWebUI fork made specifically for WebAssembly, I don't know if some of the recent PRs contain any code from that fork. Let me know if that's true, I think we should mention it in the "Acknowledgements" section then.