TokamakUI / Tokamak

SwiftUI-compatible framework for building browser apps with WebAssembly and native apps for other platforms
Apache License 2.0
2.57k stars 106 forks source link

Production readiness? #99

Open zdnk opened 5 years ago

zdnk commented 5 years ago

Hello, I would like to ask you about confidence of using Tokamak in production applications for e-commerce.

MaxDesiatov commented 5 years ago

Hello @zdnk. Many thanks for considering Tokamak as a framework for a production application! I'm currently in the process of transitioning a few of my personal indie iOS apps to Tokamak, but this hasn't been released yet on the App Store.

You might be interested in checking out this article first, which is an opinion on Tokamak by an independent developer.

iOS support for Tokamak is quite stable for simple apps, but I haven't done any thorough end-to-end testing yet with applications that would need to handle a lot of data. One of the benefits of Tokamak is that you can use it in isolation for a single view controller that you can embed in your app to try it out, and I'd be happy to hear what improvements you'd like to see in it. My co-maintainer @hodovani is working on Tokamak pretty much full-time these days, and we're ready to quickly fix any issues reported by the users.

I would personally advise against using Tokamak for macOS apps, as macOS support is pretty much a proof of concept at this stage. I'm holding off any significant macOS renderer improvements until more Marzipan details are announced in a few weeks at WWDC. More clarity from Apple on the future of AppKit would greatly help us in designing better macOS support.

As for the developer experience, when developing with Tokamak we currently see confusing messages from the Swift type checker in the case of type errors. This is a problem with the Swift compiler itself, and it's my current goal to find the best way to improve the type checker, or to build developer tools that work around this problem. One of such tools is Tokamak Linter, which is currently in development, its documentation is published in this repository and its development is tracked in #77.

I'm very interested to hear, what would indicate production readiness of a framework like Tokamak for you personally?

agg23 commented 5 years ago

What do you think the future of macOS support is given the SwiftUI announcements at WWDC?

Where do the issues lie in the macOS part of the frameworks? Is it simply in the lack of components and testing, or are there more intrinsic issues?

MaxDesiatov commented 5 years ago

Thanks for the interest, I'm going to update the README with more thoughts on this.

I still haven't had enough time to play with both SwiftUI and Combine to form a very specific opinion on this. Overalll, I quite like the new direction that Apple has specified and I think the future of Tokamak is to at least try to become API-compatible with SwiftUI.

This certainly means that API of Tokamak will change too. Firstly, because the new DSL feature makes it much easier to build node trees. The existing AnyNode API in Tokamak now seems very hacky compared to that. Secondly, I'm not sure if hooks make sense anymore given how state management works in SwiftUI and Combine.

My current plan is to wait until @propertyWrapper and the new DSL features land and are more or less stabilized in Swift 5.1, so that we can start prototyping an API with those.

In the meantime I'll be looking into SwiftUI in more details to understand what amount of work it would take to make Tokamak more API-compatible with it.

MaxDesiatov commented 5 years ago

Just to clarify, I do think it would be great to keep an architectural compatibility with React Hooks too, but I don't think that's achievable. As usual, all contributions that help in this are welcome, but given the amount of resources that SwiftUI has at its disposal, it's much more realistic for Tokamak to focus on supporting SwiftUI API on older iOS/macOS versions and potentially Android, Windows, WebAssembly etc. It's much easier to plug into the nascent, but already strong SwiftUI ecosystem, than to try to port concepts strictly from the React world to Swift. I'm very open to your suggestions if you think otherwise.

rnantes commented 5 years ago

@MaxDesiatov I'm interested in a SwiftUI cross-platform alternative especially for Android, Windows, Linux, and the Web. I see that the Flutter framework uses Skia under the hood as its main portable 2D graphics library which has support for multiple GPU back-ends (Vulkan, WebGL, meta etc). What do you think of a SwiftUI/Tokamak like framework with a Skia back-end to bootstrap cross platform support?

MaxDesiatov commented 4 years ago

Skia as a rendering backend looks interesting, but as far as I'm aware, the problem is that apps built with Skia don't look very similar to native apps, render fonts differently, and also have problems with accessibility support. Skia renderer could work better than no renderer, at least on certain platforms. It could certainly work as a separate project, and could be even merged into Tokamak if it seems stable enough and there's a demand for it.

majortom64 commented 4 years ago

How reasonable would it be to write a SwiftUI based iOS/iPadOS/macOS app and expect to deliver some reasonable subset of it via Tokamak and Swift WASM? Thinking about an application with a fairly simple forms-based interface. Backend is Vapor and would love to have minimal (no? :-) ) JavaScript.

MaxDesiatov commented 4 years ago

Hi @majortom64, we're a bit far from that, only a few basic views are currently implemented. If this is a commercial application or anything serious like that, I think the most critical issue in the end would be the binary size as discussed in https://github.com/swiftwasm/swift/issues/7. You may be able to strip the file down to just a couple of megabytes, but that would probably still be worse than using JavaScript in a lot of scenarios where you'd like your website to load quickly. The binary size issue is being worked on, but it requires a lot of work in the Swift toolchain itself, you can also follow the progress in this Swift Forums post.

If by any chance the resulting binary size is not an issue in your case, what views and modifiers would you like to be implemented first? I guess Form and related types would be the top priority? What else would you like to see in Tokamak sooner rather than later?

By the way, sorry for nitpicking, the correct name of the umbrella project is SwiftWasm, "wasm" is not an acronym 🙂

shial4 commented 1 year ago

Whats is the status nowadays? Ho far are we from production readiness?

davdroman commented 1 year ago

👆 interested to know as well as I'm considering launching a production website written in Vapor and would like to know how feasible it is to use Tokamak for the front-end layer.

gevartosky commented 1 year ago

Same here :) would love to work with vapor and Tokamak ❤️