krzyzanowskim

the Web is probably the most limited platform today to build custom text editor, in terms of text layout, interaction and all the small bits that may matter. It is still lacking proper API to interact with the OS input system outside the browser built-in text capabilities. That's why the <canvas> approach is so painful, and everything else is "limited" by the HMTL and Browser implementation details.

Very ambitious and fantastic pet project. In my opinion doomed to share the Flutter fate that has similar goal of reimplementing the entire OS UI layer (liquid glass hit flutter very hard for that reason). Technically that "does not scale" after a while, given it's reverse engineering effort. It is far from pixel perfect today, and (my prediction) will not improve much. some aspects are impossible to copy Apple design pixel perfect on the UI level, not to mention on how SwiftUI modifiers may behave. Great work nonetheless

Flutter is not the "right way", due to the nature of Flutter being a lousy reimplementation of a UI frameworks.

Marketing departament went ahead and drop "battle-tested product" nobody ever battle tested.

I think people should use anything but SwiftUI.TextEditor is my current stance

I don't know where's the improvements, give it has all the limitations, now scaled to rich text. That's not the direction that this component should get. It need radical new API that is not much compatible with SwiftUI API

totally. the there's a lot complexity that adds up to the overall performance issues. and TextKit 2 IS pretty bad at things. especially public API is pretty bad - that result in my case need to workaround things that I should've not. I agree with the general sentiment et all. I also still believe there is a place without bringing the whole browser machine to render text, and have text under control - but without relying on the "TextKit" level. That's the next thing I'm researching right now.

SwiftUI, (but not specifically "SwiftUI", more of paradigm) is not the right tool to incremental changes of large portion of data, and SwiftUI specifically is very bad at it and offer no good API to make incremental changes more optimal. That's one of the reason behind why Apple to this day did not ship usable SwiftUI text view component.

I think you should stick to what works for you best