Skip to content
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

Production readiness? #99

Open
zdnk opened this issue May 26, 2019 · 11 comments
Open

Production readiness? #99

zdnk opened this issue May 26, 2019 · 11 comments

Comments

@zdnk
Copy link

zdnk commented May 26, 2019

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

@MaxDesiatov
Copy link
Collaborator

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
Copy link
Contributor

agg23 commented Jun 13, 2019

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
Copy link
Collaborator

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
Copy link
Collaborator

MaxDesiatov commented Jun 13, 2019

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
Copy link

rnantes commented Aug 15, 2019

@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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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 swiftwasm/swift#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
Copy link

shial4 commented Sep 27, 2022

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

@davdroman
Copy link

davdroman commented Dec 16, 2022

👆 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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

8 participants