Why not TKO?
Sorry for raising this as an issue, couldn't find any other way of making contact with you easily! Just wondering why you chose to rewrite KO instead of taking up TKO?
That said, you currently seem a lot more active than the TKO repo, and I feel like with the all the talk about signals being the way forward etc. right now is the perfect time to pull people back to KO in general. I feel like this project could be a good thing for that, but probably deserves a new name & site etc. to go with it.
Have you run performance comparisons between the final official KO, TKO and this? Would love to chat some more.
I am not an owner / developer of this repo, but I can tell one thing that TKO is not fully compatible with the existing large knockout code base. For example, nested with is not supported by TKO, while I had nested foreach binding with nested with binding in my code.
See also https://github.com/knockout/knockout/issues/2587#issuecomment-1030946410 for the another examples of the incompatibility. It's not a drop-in solution, it requires refactoring and it may be less convenient.
Hi there, to be honest, I found myself in the middle of this "KO overhaul" before I even actively decided to ;-) It was curiosity in the KO sources first, then I felt the need for a cleaned up / modernized yet compatible drop-in replacement for my projects without ancient browser requirements. So my intentions were rather selfish and "conservative" as opposed to TKO's massive progression towards Knockout 4, which I have huge respect for.
I haven't run synthetic performance comparisons between the three, so if anyone puts energy into getting some useful measurements, I am all ears.
Fair enough! Might have a go at working a performance comparison out sometime. We use TKO (previously KO) in a commercial project and have been since 2015. I think it speaks to the viability of the framework that to date we've never had a major issue or problem we couldn't solve easily.
@Dmitri-Sintsov Yeah we had to make a few small changes to incorporate TKO, and I've found the afterRender things don't work right. What's a shame is that it seems to have lost all momentum and isn't very publicly visible. I feel like if we could pull together the dregs of the KO community it would be a good time to start getting it pointing in the right direction.
@justlep We've got the better part of 30k lines of JS/HTML templates that are all built with TKO/KO - will see if I can drop your version in sometime just as a test - would be interesting to see how well it works!
Fair enough! Might have a go at working a performance comparison out sometime. We use TKO (previously KO) in a commercial project and have been since 2015. I think it speaks to the viability of the framework that to date we've never had a major issue or problem we couldn't solve easily.
@Dmitri-Sintsov Yeah we had to make a few small changes to incorporate TKO, and I've found the
afterRenderthings don't work right. What's a shame is that it seems to have lost all momentum and isn't very publicly visible. I feel like if we could pull together the dregs of the KO community it would be a good time to start getting it pointing in the right direction.
I use afterRender in my code and it's very convenient in some cases. While I guess that custom binding can be used to emulate it, still it's strange why TKO does not support it.
Things with Ko become worse when Microsoft decided not to actively support Knockout development and the lead developer @mbest become Microsoft React libraries developer instead.
I tried to move to Vue but it seems too heavy and virtual DOM prohibits proper cooperation with third party libraries. I head that Alpinejs is being more actively developed in recent year, however I am not sure is it flexible enough to be used as a library, not framework.
To me Knockout.js is the "better version of jQuery", not React or Vue replacement.
Thanks @mattlacey, all feedback is highly welcome really.
A pain point I see which may be preventing more people from even trying (original) Knockout is the lack of up-to-date IDE code assistance through the .d.ts from DefinitelyTyped, @types/knockout. Sadly, it has never been updated to fully describe Knockout 3.5.1.
Funny you should say that - we're putting TypeScript in place at the moment, Iand we dropped in @types/knockout. I was quite surprise that it takes care of the types observables should contain, such as observables that should only take booleans.
On February 2, 2024, GitHub @.***> wrote:
Thanks @mattlacey https://github.com/mattlacey, all feedback is highly welcome really.
A pain point I see which may be preventing more people from even trying (original) Knockout is the lack of up-to-date IDE code assistance through the .d.ts from DefinitelyTyped, @types/knockout @.***/knockout>. Sadly, it has never been updated to fully describe Knockout 3.5.1.
— Reply to this email directly, view it on GitHub <https://github.com/justlep/knockout-esnext/issues/15#issuecomment- 1923657710>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AAJSWW5YO6PWCZMJCVA7CSLYRTHWFAVCNFSM6AAAAABCE7NSYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRTGY2TONZRGA>. You are receiving this because you were mentioned.Message ID: @.***>