Is this project still alive ?

[NinjaCross]

I really like this project very much, but I'm a bit concerned about the fact that there are still many (old) opened issues, and it seems it's no longer actively maintained. My main concern is related to the usage of this library into a couple of big projects I'm going to start this year. My customers are raising questions about the potential impact caused by the usage of abandoned / not evolving dependencies. Are there future plans and evolutions for this project in the foreseeable future ? Is there the realistic possibility that the significant amount of opened issues (at least the bugs) are closed in the near future ? Thankyou for you answer :)

[bludev]

I think an open-source project can only survive if the community supports it, otherwise it will be doomed to die. So if there are errors or missing features, anyone can make a pull request to improve it. True, the repository looks desolately abandoned. However KO is a mature project that doesn't require a lot of maintenance, I've been using it for years on all my projects and honestly I don't miss anything. I am more concerned about the situation of TKO, which should represent the future of KO, which has been standing still for quite some time. In recent years web browsers have evolved, some have almost disappeared (IE, Edge legacy). it would be time for KO (through TKO) to remove the old design constraints and finally use all the new technologies available in modern web browsers. Of course without distorting the basic concept of KO that I have always loved: its "low-level" nature and not a complex framework like in other similar libraries.

[NinjaCross]

True, the repository looks desolately abandoned. However KO is a mature project that doesn't require a lot of maintenance, I've been using it for years on all my projects and honestly I don't miss anything.

I'm concerned by the fact that there are (now) 285 issues in "open" state, and many of them appears to be bugs

[mbest]

@NinjaCross If you're running into a problem, please let us know. There are still people active on here, the Google group, or on StackOverflow.

I'm in the process of working on a 3.5.2 release with a few bug fixes. Hopefully before the end of the month.

[PaulHuizer]

@NinjaCross Knockout is working robustly for a long time now. No way this technology is obsolete or dead. Its a fundamental building block for many sites. On top of that, the project has @mbest is a topnotch maintainer who keeps an eye on the ball with regards to breaking issues. There still is a large need for this type of unopinionated and compact frontend framework.

[NinjaCross]

@PaulHuizer , I think you are misinterpreting the very nature and intentions of my question :)

I repeat: I really like this project very much, but my customers really don't care about what I "like". They base their concerns on the facts I mentioned, not on personal opinions.

Knockout is working robustly for a long time now.

As far as I can see, your opinion is not supported by the number of opened issues.

As I said, there are 285 opened issues. https://github.com/knockout/knockout/issues?q=is%3Aissue+is%3Aopen

165 of them (57%) are not labeled/tagget, so it's impossibile to evaluate how many of them are bugs (my customer's primary concern) or just requests for new features. https://github.com/knockout/knockout/issues?q=is%3Aissue+is%3Aopen+no%3Alabel

There are also 72 opened pull requests, leading to think that there are fixes and/or features not yet integrated. https://github.com/knockout/knockout/pulls?q=is%3Apr+is%3Aopen+ Maybe this is by choice, obviously not all the PR should/can be merged, but if they are not usefull or there is no intention to merge them, they should be closed.

Given these stats, how could anyone know if the project is stable or just abandoned ?

No way this technology is obsolete or dead.

I didn't said nothing of the sort :)

Its a fundamental building block for many sites.

Again, I like this project, and I tend to agree on the fact that it's still used (the Star History suggests a stable trend)

I'm just raising a legitimate question based on numbers, not opinions.

On top of that, the project has @mbest is a topnotch maintainer who keeps an eye on the ball with regards to breaking issues.

I'm not questioning the ability or the efforts of @mbest .

Again, I'm just concerned by the significant quantity of unlabeled issues (leading to think there are a lot of unresolved bugs) and unmerged pull requests.

There still is a large need for this type of unopinionated and compact frontend framework.

Again, I never said it's not a good project. As I said, I think you are misinterpreting the very nature and intentions of my question :)

[NinjaCross]

@NinjaCross If you're running into a problem, please let us know. There are still people active on here, the Google group, or on StackOverflow.

I'm in the process of working on a 3.5.2 release with a few bug fixes. Hopefully before the end of the month.

@mbest Thankyou very much for you effort :) As I explained to @PaulHuizer in my previous comment, the concerns raised by my customers are based on the general stats of unlabeled&open issues, and on the number of unmerged&unclosed PRs. My I ask why they are so ? Maybe an explanation would be enough to keep my customer's concerns at bay :)

[wilson0x4d]

perhaps some triage work needs to be done on issues, and perhaps some supporters of the project can help with triage (tagging) to reduce the workload required by contributors/owners.

i still use knockout after what I believe is 10 years or so, i find no other library that provides the same support. I've even created variants of knockout for languages like Lua since it works very well for a broad range of problems (which normally require a bridge or IPC-like layer between components.) for probably 4 years haven't noticed any bugs myself nor needed any new features, I do see this a a testament to the robustness and quality of the code, today.

again, perhaps some triage is necessary to clear out or prioritize some of the bug reports.

[Jaynator495]

@NinjaCross If you're running into a problem, please let us know. There are still people active on here, the Google group, or on StackOverflow.

I'm in the process of working on a 3.5.2 release with a few bug fixes. Hopefully before the end of the month.

I have my fingers crossed that it includes a fix for #2560 because I had to revert to 3.4.2 for my project (QuestionCove), Because it caused a bug with the index value being 0, passing non-existent values to a callback function which results in bugs in the UI, It's honestly the only major problem I've ever had with knockout.

In my case it was a little different from the bug described in that mine is attempting to get data from the previous element to check if something was the same as in the current element, but sometimes it was just return 0 for all iterations

I was starting to have the same question if it was dead because I was checking up on this a couple times a month for a good 6 months and was hopeful once I saw the issue opened up because I knew I wasn't just crazy

[jonbnewman]

I'm gonna be honest here guys. As a person who writes code for a living...I think:

• If you want to be employed
• If you want to hire other devs to work with you
• If you want your project maintainable long-term wise
• (honestly) If you don't want whoever takes over your code base to hate you

...then it is time to move on.

I say this as a guy who spent a couple years writing a framework around Knockout (http://footworkjs.com/) a while back. I eventually let that project decay and become dormant because I saw the writing on the wall for Knockout...and for my professional careers health, I had to move on.

I lived and breathed Knockout for years, I wrote a TON of apps with it (many which are still running) for both work and personal use...I proselytized it wherever I went...I wanted it to succeed. However at this time - even with TKO - I just don't see it happening. The community, the momentum, the sheer amount of support and interest around the big name projects is just too strong to ignore (React/Vue/Angular).

The world is moving on...I've moved on...

I say all of this with absolutely no disrespect for mbest or anyone else involved in the development of Knockout...it is and was a great library. I learned SO MUCH writing apps with and a framework around Knockout...it was way ahead of the curve when it was originally released, I absolutely loved it.

But Knockout will not survive with so few contributors and people working on it. Michael cannot do it on his own, he has a life and other responsibilities that pays his bills - so reality is unavoidable. Last word from the thread above is that Michael thought he would have a minor release done by the end of March...it is now May (https://github.com/knockout/knockout/issues/2564#issuecomment-803654927). I am not pointing this out to knock Michael or be mean...I am just pointing out I realize Knockout doesn't pay his bills and he's one of the only active contributors to Knockout...life takes precedent. However this also means Knockout is placed in a precarious (and IMO untenable situation).

I personally moved on to React about 3-4 years ago...and honestly I love it. Once I got over my prejudices concerning JSX/etc and built a few apps with it...I fell in love (also, observables are available in React - see mobx). I am not telling everyone to switch to React...but I bring it up to point out that there are other options out there...many of which you may find you like...maybe just as much, if not more than Knockout. This was my experience.

Honestly...congrats to mbest and the rest of the Knockout crew...they played a significant role in shaping the future (now present) of the javascript landscape.

[samuelkdavis]

I would agree with @jonbnewman that React + mobx is the way to go if you like knockout, but want to use a framework that isn't in the process of being abandoned.

[wilson0x4d]

.. in addition to KO I also use Angular, React, and Vue. All I can say is corporate developers are masochists, and that money is power. The problem with Angular and React is they aren't necessary, but you have droves of developers that can't tell the difference between TypeScript and Angular/React, even more don't understand what webpack is. You essentially have a captive talent pool that will never really be able to do anything beyond copy and paste what others have done before them.

Much shame.

What we're really advocating with these frameworks is akin to non-open standardization of technology for the sake of making useful people of very low skill and reliability. Can you implement a React component without using the React toolchain? Not feasibly. Can you implement an Angular (2 or later) app without leveraging any Angular decorators? Not really. Can blithering idiots successfully author entire applications using these frameworks? Yes, absolutely, without understanding how half of it works.

On a long enough timeline all technology fades. Angular and React will be no different. There are hundreds of languages and libraries in existence today where large percentages of developers believed they would last forever, would form the backbone of technology, and that investing in them was investing in one's future. To date this has been largely untrue with very few exceptions.

So to counter some of the junior advice here:

• If you want to be employed
• If you want to hire other devs to work with you
• If you want your project maintainable long-term wise
• (honestly) If you don't want whoever takes over your code base to hate you

Be prepared to learn everything, forever, until you retire. Don't get too attached to something you love because eventually it is going away. If you are just starting out basically just copycat everyone around you, it's all going to change in 3-6 years anyway, why waste time mastering technology that ages faster than you do?

I've been coding professionally for 35 years. This is the way of things.

That said there's nothing wrong with sticking to what you enjoy. I still write KO code because it takes minutes instead of hours to build a full application. I still write C/C++ code when doing embedded development. I still use Lua and Python when writing code for niche chips like ESP's, I still humbly develop on Windows, Linux, and macOS just to keep current. What I appreciate most about KO is even as technology changes it still works, which is something I despise about Angular, React, and back-end UI frameworks (of which there are now dozens) because they degrade and break as technology advances, their owning corps eventually force migrations on everyone, and every few years a new set of employees come along that want to change All The Things(tm) because, well, that's what freshmen do!

What I'm really hearing is FUD from people that have moved on.

Personally, as a KO fan.. it would be nice to see KO get a facelift in the toolchain department, if only to capture the segment of the community that can't be bothered to write any code unless npm start does everything for them. I'm not saying KO needs to change, but, a secondary layer built for Knockout that brought webpack, npm, and typescript modernization via a standard set of scripts would be very, very nice. Beyond that, I think knockout could use some simplification of data-binding without really changing how it works (ie. without breaking compatibility.) I mean look at JSX, it's a glorified parser/loader sitting on top of webpack. Angular components aren't much different. It could be pretty neat to see KO get a similar level of parsing so that templates could be rolled into a 'build' via webpack. This is something we have to do manually today.

Suppose it just requires someone with enough free time to bother.

I would vote to close this thread since it's clearly degraded into a thread about discouraging adoption. If you want things done faster, remember, it's FOSS, you can always fork the project.

[PaulHuizer]

Most who have seen more than one tech wave, know that in the end no-one is served best by the idea that the only way to move forward is to have everyone agree on the single best option. Just like it simply is not a wise idea to continue debating about who has the nicest pair of pants. Tech to many is not fashion. The DNA of KO is unopinionated. People who recognize that wont stop appreciating that.

[jonbnewman]

@wilson0x4d

So to counter some of the junior advice here:

I've been coding professionally for 35 years. This is the way of things.

Nice ad hominem, and nice to paint yourself as an authority who cannot be questioned...

I've been writing software professionally for 22 years, frontend specialized (although I wrote a lot of javascript my entire career) for the last 9 years. I know javascript VERY well and have used MANY frameworks. I've even (as mentioned) authored my own.

Currently I write a ton of typescript and javascript daily, as well as manage and mentor other developers in a principle (senior of seniors) frontend role for one of the giant oil companies. I've worked in MANY industries over my career, at my present employer I was hired to modernize their methodologies and build cool stuff - both of which I do very successfully every day.

Building maintainable, transferrable, extendable complex projects with other developers and interested parties all incorporated....its what I do.

You are not dealing with a 'junior' or 'junior advice' here.

Be prepared to learn everything, forever, until you retire. Don't get too attached to something you love because eventually it is going away. If you are just starting out basically just copycat everyone around you, it's all going to change in 3-6 years anyway, why waste time mastering technology that ages faster than you do?

That is absurdly not at all my argument. This is straw-man. It's about choosing an appropriately supported and maintained tool that does a good job at solving your problem.

Want to stick with knockout?

1. Good luck finding a high-quality developer that wants to work on your project.
2. Good luck finding well supported tools that help you solve your problems easier with that unsupported library/framework. (now we get to write everything custom! yay!)
3. Good luck getting that issue about it addressed that you posted on github
4. Good luck passing off your project that very few developers know or will want to work on in the future
5. Good luck incorporating it into modern build methods easily (the other tools its a command line away, but you'd rather spend tons of time tweaking custom webpack configs and maintaining the build pipeline yourself I suppose)
6. etc etc

There are MANY many perfectly valid reasons not to use an unsupported piece of tech...stop insulting those who bring it up.

That said there's nothing wrong with sticking to what you enjoy.

In this specific situation there is if your task is to write maintainable modern software that other developers in a team want to or will work on or a project that you can easily hire a replacement for. Or if you want issues addressed. Or if you want to not have to write custom widgets/components that other libraries have drop-in higher quality replacements for. Or....you get the idea...

...but you instead want to call me a 'junior' for bringing up valid critique. THAT is shameful.

All I can say is corporate developers are masochists, and that money is power.

...what? This isn't about money or power...this is about creating maintainable, extendable, complex software that people who follow me or people on my team can and want to work on.

You honestly sound ridiculous. These are tools...this isn't a religion - see if they are useful for you and if so, use them.

What I'm really hearing is FUD from people that have moved on.

No, you are hearing the reasons people have moved on and then trying to dismiss the argument with ad hominems and straw-man arguments instead of considering the content of the critique.

I would vote to close this thread since it's clearly degraded into a thread about discouraging adoption. If you want things done faster, remember, it's FOSS, you can always fork the project.

It would require an active maintainer to do that...

(I mean I'm sure he'll read this eventually...but the fact he hasn't read and addressed my comments [nor has he made a commit, or commented on anything else] himself in the nearly 2 months since my post kind of proves my point as well).

[groovenectar]

I recently put together a project with KnockoutJS and am super happy with the framework, feeling that it was the absolute perfect choice. It was my first time using Knockout, having used both React and Vue before.

If anyone is looking for a solution to using native date/time inputs in a component-based approach, I just published this part of the application today: https://gist.github.com/groovenectar/814703d1bc260859b8600e9d8a917b4d

That was the one big hurdle for me... didn't find a lot of examples of using native date/time pickers as observables... so now there is one! There are 3rd party datepickers out there, but I think this native approach is a really ideal and future-proof solution that can expanded upon (also would love to hear feedback for improving it). I appreciated this challenge, and everything else was really smooth sailing thanks to an excellent framework with great documentation.

I checked back in on the GitHub repo to check the pulse and found this thread... and figured the fact that someone has recently decided on KnockoutJS for a new project would be relevant.

[jonbnewman]

@groovenectar

I recently put together a project with KnockoutJS and am super happy with the framework, feeling that it was the absolute perfect choice. It was my first time using Knockout, having used both React and Vue before.

A lone developer picking something for something he alone works on...proving my point further. Also, its not a framework, its a data-binding UI library....thats why I was at one point writing an actual framework around it.

If anyone is looking for a solution to using native date/time inputs in a component-based approach, I just published this part of the application today: https://gist.github.com/groovenectar/814703d1bc260859b8600e9d8a917b4d

So you wrote a custom component for something that didn't exist, and release it in a gist as a 'solution'...yet again, proving my point here. No one is going to be able to find your random gist because its not a supported project...what happens when an edge case occurs for someone that you didn't cover in your singular use case? What happens when someone wants a new feature you didn't think of? What happens if they have questions about how its used?

You can't hope to compete with publicly available UI kits and their support/documentation/maturity (things like Material UI and Chakra UI, etc, etc)...

I checked back in on the GitHub repo to check the pulse and found this thread... and figured the fact that someone has recently decided on KnockoutJS for a new project would be relevant.

Oh its relevant...you are a lone developer working on a project by yourself writing custom components to fill in what is missing.

Literally proving my point...but you had to downvote me first and heart-emoji the comment that supports your backward thinking in chosing knockout for your project...

Honestly at this point, I find it humorous how much resistance there is to absolutely basic common sense reason. I have not said anything controversial...just things people didn't want to hear about their favorite library that people (generally) avoid these days (for good reason).

[webketje]

Well I happen to have found @groovenectar 's gist. I don't often use Knockout anymore because the job market dictates what I use. There's a niche case I found Knockout to excel at: slapping together a custom form that toggles component states for managers and analysts to validate designs, and it is waaaay faster to set up and more lightweight than setting up a Storybook.

Obviously the answer to OP's question is yes, this project is still alive. And obviously @jonbnewman has a point that it is not as vibrant as it used to and will never catch up with the newer kids. Yet there are other very, very old projects (GetSimpleCMS, GtkRadiant, QCubed) that despite no longer being 'in', maintain a healthy, -niche or other- user base. GtkRadiant is over 20 years old and still actively developed. GetSimpleCMS hasn't had a major release in over 3 years, yet it has thousands and thousands of users and developers using it.

There are tons of reasons to avoid Knockout (loop render perf, under-the-hood eval a.o.), yet it still brings value with its lightweight observable, 2-way data-binding & component structures and has valid use-cases (prototyping, for projects where compilation is not an option, enhancing older websites without having to refactor everything with a modern pipeline, integrates well with requirejs-based systems).

Have you seen the docs for Mobx? I just want to slap a ko.observable on the page and move on with development, not read a book about observables. I'm not bashing Mobx, just saying there's a different audience for these tools. Two-way binding has fallen out of grace due to industry leaders hitting its limits on larger apps and blogging about it, but it is still way easier to grasp and get going with than React's onChange -> callback -> state update -> prop update mechanism, or Vue's :model binding.

[jonbnewman]

@webketje

Well I happen to have found @groovenectar 's gist.

Finding a random gist because you happen to be reading a specific issue on github is not a replacement or comparable to the plethora of libraries and components you can easily find/stumble-upon with other libraries/frameworks.

Here is a handful off the top of my head (for React, specifically):

https://material-ui.com/ https://chakra-ui.com/ https://blueprintjs.com/ https://primefaces.org/primereact/

All of these are well supported, widely used and battle-tested frameworks that provide date pickers and tons of other supporting components that will save you tons of time and are very much higher quality than a random gist someone authored in an afternoon.

...these do not exist for Knockout.

There's a niche case I found Knockout to excel at: slapping together a custom form that toggles component states for managers and analysts to validate designs, and it is waaaay faster to set up and more lightweight than setting up a Storybook.

npx create-react-app app

Boom...full auto-building environment that I can begin styling and creating my form. You don't need storybook for quick spin ups of apps...and its definitely faster than even setting up knockout is once you know the tooling and generators available for React. And these generators come with all sort of handy tools/etc with them free of charge that would take a while to setup with knockout.

Have you seen the docs for Mobx?

I am not trying to argue for MobX (and I agree it's docs could be better)...I only used it when I initially switched to React because it provided an easier mental switch going to React. And I only mention it in this context for that reason. There are a ton of options in React when it comes to state management, and MobX is only one of them. I do not personally use MobX anymore, there are better alternatives IMO.

That said, MobX is very capable and easy to use...once you take a few minutes and learn how to read the docs (it really isn't that difficult despite the initial shock that the docs might give you).

And I am also not even saying you should switch to React...just that, using knockout in your next big project probably isn't a good idea, especially if you work in the context of a team, or with a project you plan on passing to another developer at some point. Can you use Knockout? Sure...it will still run, and if you absolutely love its syntax and don't have to worry about working with other developers then sure go ahead and use it, it's only your personal project at that point.

But if you plan on being paid for your work, working with a team, something modern with modern tooling support, something that has an active community, something that has active and well supported 3rd party components/libraries, etc etc...then its time to look to alternatives.

Even for personal projects, I'd argue you should look for something that is actually supported and isn't dying...but its obvious we have a lot of fan boys here who still can't get over the realities of the situation knockout finds itself in.

I've been there, it took a lot for me to stop working on the framework I had been authoring around knockout for over 2 years...it really hurt to realize the project I had so much passion for wasn't going to happen and it was because knockout itself was dying.

It was painful to switch to something else honestly... but in the end it was very fruitful and worthwhile.

I also learned that there are very real, and very good reasons people use React (or other alternatives). They are actually very powerful, and fun to use in their own right - once you know them well enough...but yes, you have to invest time into learning a new tool and its ecosystem.

[groovenectar]

@jonbnewman There is clearly a deeper issue going on, some kind of bitterness or heartbreak being displaced... Of course you were downvoted, and I think if you revisit this thread in a year you would undererstand why and do the same thing.

The fact that you had started to write a framework around Knockout could be indicative of where the bitterness comes from, perhaps? Maybe you realized you were coding yourself into a corner, and ultimately you know that the problem was not Knockout. But I can see where you were reaching for a goal and maybe found that someone else had implemented it at some point.

No one is going to be able to find your random gist

They absolutely can, at least, and one reason I know that is because I linked it in an SO thread that I came across when I first looked around. When choosing Knockout, it was not one of my requirements to not have to do anything on my own and copy and paste every possible aspect. Implementing the component was a perfect way to dig deeper.

I like the solution that we came up with for this application, and it positions us to refine the user experience as we go without adding bloat or heavy datepickers that may end up detracting from the user experience. I don't actually see anything in the React ecosystem that accomplishes the exact same thing, but just like with Knockout I'm sure that someone somewhere has implemented it, maybe privately. Including any of those bloated React UI frameworks that you mentioned into the project would have skyrocketed the load to very little benefit.

Today, within about 45 minutes I was able to transform the application into a "widget" that can be included on any other website using one line of code. The entire application including CSS, HTML, JS, and Knockout dependency transfers in 34.26 KB :) Not too shabby I think, and in just a few hours it's getting some positive feedback from its target industry. I'm proud of how it turned out, and could not be more pleased with the decision to use Knockout for it.

If you insist on only going with a framework that has tons of commits and merges on a weekly basis, then you are going with something that is not exactly stable. Knockout is not dying... Knockout is rock-solid, and also more than reasonably future-proof. It doesn't need to have commits every week. A lot of the newer kids have vastly different motivations for "innovating" or even existing. Things tend to come back around towards pure eventually, so there's even a chance that the newer kids will be playing catch up at some point in some way.

A coworker caught wind of Knockout and linked it to me, and that's how I found out about. I will continue to recommend it for plenty of use-cases. For a widget-based application it really exceeded expectations.

[jonathanshell]

@groovenectar

There is clearly a deeper issue going on, some kind of bitterness or heartbreak being displaced... Of course you were downvoted, and I think if you revisit this thread in a year you would undererstand why and do the same thing.

There you go trying to dismiss valid arguments...no...I am not bitter. This is me expressing the reasons that I left the knockout sphere, and then defending them to very disingenuous (and often condescending) arguments like yours trying to dismiss valid critique.

To flip the script a bit and be as insulting to you: Maybe you are just upset you are wrong? Why are you upset that your favorite library is dying? Why are you so upset that someone said you were wrong? You sound bitter and angry and maybe you should address that?

See how insulting that is? I didn't even consider your argument, I just called you angry for having one....

They absolutely can, at least, and one reason I know that is because I linked it in an SO thread that I came across when I first looked around.

You found it because you are reading this thread. That is NOT AT ALL THE SAME as a publicly indexed and often referenced (in MANY SO posts/etc) website that has documentation, examples, etc, etc.

You cannot compare a random gist someone posts in an afternoon that is referenced on a github issue to a publicly posted and properly registered project. There are SO MANY things provided by an actual project that a gist has no hope to provide.

That argument is flat out ridiculous.

If you insist on only going with a framework that has tons of commits and merges on a weekly basis, then you are going with something that is not exactly stable.

No, do not inject words into my mouth. That is not at all what I am saying...to put it in one simple sentence: I am saying you need something with a future.

Knockout is dying (dead)...the sooner you guys realize this the better. Does it still 'work'? Yes...the same as it did 5 years ago...that doesn't mean it's not dead.

Things tend to come back around towards pure eventually, so there's even a chance that the newer kids will be playing catch up at some point in some way.

How delightfully condescending...if only the stupid kids knew better!

A coworker caught wind of Knockout and linked it to me, and that's how I found out about.

Not sure I believe this statement (unless you are talking about a conversation you had years ago)...regardless though, good luck hiring a team of people and having a long term project around Knockout that attracts quality engineers (hint: you won't).

[PaulHuizer]

With such lively and lengthy discussions going on, would it not be reasonably accurate to say this repo is alive and kicking ;-)

[jonathanshell]

@PaulHuizer

With such lively and lengthy discussions going on, would it not be reasonably accurate to say this repo is alive and kicking ;-)

No...its like 2-3 of us going back and forth discussing the fact that it might be (is) dead.

And most importantly: Not a single (or rather, the single) maintainer has chimed in on it in months.

That's not alive...thats a very dead body that is twitching...and boy does it stink. It's like Weekend at Bernies and you guys are the ones driving the dead body around town, refusing to accept reality (and insulting anyone who dares mention the fact you are carrying a dead body around).

[webketje]

Yes npx create-react-app app is convenient to hit in the terminal on the desktop, waiting 5 minutes on a high-latency connection for 500MB of dependencies to be installed on a less powerful pc not so much. Still, not every developer/webmaster has access to these tools (think of a corporate laptop where devs are not allowed to install anything) and for many it may be easier to add a single script to a Drupal template/ SAP system and roll your own Knockout component.

The webmaster/ CMS developer's tools may no longer be suitable to the software engineer, that only means it has a different future. The former just needs to develop a few content type pages with a bit of dynamic JS, the latter needs to develop a full SPA app powered by ultra-clean reusable components, microservices, using SSR and whatnot (just an example). Knockout is still suitable for what it was suitable for when it first came out.

Can't we just agree to disagree and not degrade the thread into a flame war? Most of the arguments given are valid but you just operate in a very different context. If Knockout still has community and a moderately active maintainer, even if you don't identify with it, it is alive. Just imagine how outrageous it would be if you were talking to the person and then insisting on it: "Pops, you're 53 and not as active as you were 5 years ago, you are dead".

PS: I am not part of the group of users I may appear to defend, in fact I rarely use Knockout myself (last time was 3 years ago). I agree with "Knockout has no future in software engineering or complex apps", but disagree with "Knockout has no future at all.".

FWIW Knockout still appears in 300+ recent vacancies listed on Indeed (vs React's 12k +)

[jonathanshell]

Yes npx create-react-app app is convenient to hit in the terminal on the desktop, waiting 5 minutes on a high-latency connection for 500MB of dependencies to be installed on a less powerful pc not so much.

It's a one time cost...if your internet is so poor you can't support downloading some assets then ok - use something else. But that is like 0.0000001% of people out there - and its no reason to recommend Knockout in a more broader sense.

Still, not every developer/webmaster has access to these tools (think of a corporate laptop where devs are not allowed to install anything) and for many it may be easier to add a single script to a Drupal template/ SAP system and roll your own Knockout component.

I've worked for an employer like that before, they are few and far between and ever shrinking in numbers. But ok - for those rare cases then use something else.

Even the employer I used to work for that did that (JPMorgan Chase) doesn't do that anymore, they even have their own framework for React these days (something I never thought would happen considering how locked down and custom everything was when I worked there, many years ago).

Knockout is still suitable for what it was suitable for when it first came out.

Suitable, yes...for an older internet...which had different concerns at the time...and was far less capable. But yes, it will work...I am not saying it won't. I am saying if you want a modern application that is built on something maintained and that other developers will willingly work on - then you need to look elsewhere. I stand by that statement for the plethora of reasons in my comments prior to this one.

Can't we just agree to disagree and not degrade the thread into a flame war?

I was fine with the discussion and was completely cordial until someone started trying to paint me as a 'junior developer' or simply 'bitter' and 'heartbroken'. Which is patently ridiculous. It's an attempt to disregard criticism and it's juvenile in nature.

I agree with "Knockout has no future in software engineering or complex apps", but disagree with "Knockout has no future at all.".

That I 100% agree with.

My entire (repeatedly stated) point was that if its for your own personal project, have at it. But to argue that someone should use this on a larger project with budgets and team members, or with the hopes of being hired to develop with it - no, it is not good for that anymore and we should not be recommending it for that purpose.

FWIW Knockout still appears in 300+ recent vacancies listed on Indeed (vs React's 12k +)

Legacy code is still out there, a very few companies will hire for it (and those numbers will continue to decline).

A lot of my past projects at previous employers that used Knockout in a professional context are still out there, running. I still keep up the documentation for my old framework because there are at least 2 applications out there in the wild using it to this day.

...but that doesn't mean that in a general, professional context, it isn't dead...or dying.

[groovenectar]

@jonbnewman By supporting React in particular, one thing you are doing is supporting the technological advancement of Facebook for free. You are supporting systems with political agendas that are capable of affecting the landscape of rendering engine development for their own anti-competitive agendas and gain. This cannot be ultimately sustainable.

[jonathanshell]

@groovenectar

@jonbnewman By supporting React in particular, one thing you are doing is supporting the technological advancement of Facebook for free. You are supporting systems with political agendas that are capable of affecting the landscape of rendering engine development for their own anti-competitive agendas and gain. This cannot be ultimately sustainable.

I am just going to have to disagree with you there. Regardless, React isn't the point of my argument...not using Knockout is.

You are free to choose something else if you have moral objections to using React.

[groovenectar]

@jonathanshell React isn't the point of my argument...not using Knockout is

This is actually the rude part of this thread, not any theorizing as to why you were rude. And that's the thing you're going to see yourself when you revisit this in about a year. And people are still using Knockout, because it can and will often remain a solid choice.

One of the largest backbone internet providers in the entire world uses Knockout internally, and even for a recent application. So in a sense, Knockout helps keep the world connected. It's not dying.

[jonbnewman]

@groovenectar

@jonathanshell React isn't the point of my argument...not using Knockout is

This is actually the rude part of this thread, not any theorizing as to why you were rude. And that's the thing you're going to see yourself when you revisit this in about a year. And people are still using Knockout, because it can and will often remain a solid choice.

Having an opinion about using (or not using) Knockout is the entire point of this post (look at the title of it). It is not rude, you only think of it as such because you still use/love it. I get it...but me recommending not to use an unsupported project for new applications is not rude...it is a perspective, and it is directly related to the topic.

You are free to disagree...but calling it rude is disingenuous and dismissive - just like your other previous comments towards me.

The rude part is the ad hominem attacks against me and dismissive attitude towards valid criticisms - of which you are part of both.

And that's the thing you're going to see yourself when you revisit this in about a year. And people are still using Knockout

Well of course there will be people using it...but the number will continue to shrink...as it has been for years. I am not saying everyone everywhere will stop using it...as I said legacy code exists...and then there's people like you who also exist (who won't give it up - for whatever reason).

My argument has never been that it will be completely dropped off the internet. Just that you shouldn't be trying to recommend it for large/budgeted/team based projects...in that context...with the exception of the legacy code floating around out there - it is dead.

One of the largest backbone internet providers in the entire world uses Knockout internally, and even for a recent application. So in a sense, Knockout helps keep the world connected. It's not dying.

Like I stated prior, large legacy projects that are sticking around due to momentum does not mean a project isn't dying. Refactoring costs money and companies will do all they can to avoid it.

There is no one in their right mind recommending knockout to their higher ups for their brand new large scale app...the most you might get is a lone developer here and there picking it for a personal project - and they only do that because it is what they know and are comfortable with (or have odd moral objections against using something else)...not because its the 'correct choice' in todays modern internet.

[NinjaCross]

@NinjaCross If you're running into a problem, please let us know. There are still people active on here, the Google group, or on StackOverflow.

I'm in the process of working on a 3.5.2 release with a few bug fixes. Hopefully before the end of the month.

Hi @mbest . Any news about the mentioned 3.5.2 release :) ?

[the-djmaze]

@jonbnewman and @wilson0x4d You both should hire The A-Team

"I love it when a plan comes together"

Every code is old. How many people that use Vue are not using Vue3 (same for anything else). All projects have decay and become dormant when nobody puts the money where it should be (so that's not marketing nor managers)

[kicsiede]

string.replace is dead. it's time to move on to regex.replace

[jaredbroad]

Stumbled on this thread trying to get creative hiring a KnockOut UX Engineer 😅

Perhaps with the new GitHub sponsorships initiative, we can get some firepower for its maintenance?

[the-djmaze]

@jaredbroad there are things to consider here. There is a new Knockout project with new/faster code, but what if you can make the current faster?

I did modify current Knockout and removed all old bloat code that i don't need (no support for Internet Explorer, Legacy Edge, old versions of Firefox, Chrome, etc.) I had to modify the used google-closure-compiler for cleaner code. I had to use an additional script to remove google-closure-compiler bloat code. I have removed features i don't need. Finally i went from the original 66.6 KiB to 37 KiB and a good speed increase. See https://github.com/the-djmaze/snappymail/tree/master/vendors/knockout/build/output

Does it work for everybody? No Does it work for projects which only support year 2020/2021 browsers? Probably

So even if you do throw firepower at it, does/can @mbest upgrade this project?

[groovenectar]

So even if you do throw firepower at it, does/can @mbest upgrade this project?

Although, part of the appeal for some is encouraging an open browser ecosystem and wide browser support...

[ryanlin1986]

@the-djmaze Really appreciated your works, that's just what I need. We have a really really big libray(200K+ ts code) massively depend on knockoutjs, rewrite to other tech may be too overwhelming, that's just what I need.

Do you have plan to create a standalone repository?

[NinjaCross]

Do you have plan to create a standalone repository?

1 up !

[Jaynator495]

Honestly I have a project with a good 500k-1m lines that is heavily knockout integrated. It's practically a whole social media site, as the only developer to rewrite it would be a monumental task while still trying to provide updates. So +1 to this, it is still needed for some things. Sometimes "just rewrite it" isn't an option - as much as I want to.

On Mon, Sep 27, 2021, 10:31 AM ryan lin @.***> wrote:

@the-djmaze https://github.com/the-djmaze Really appreciated your works, that's just what I need. We have a really really big libray(200K+ ts code) massively depend on knockoutjs, rewrite to other tech may be too overwhelming, that's just what I need.

Do you have plan to create a standalone repository?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/knockout/knockout/issues/2564#issuecomment-928097447, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDPQE6HHJT5G63ONMHVXMLUECS7ZANCNFSM4ZJ5YW4A .

[ryanlin1986]

After few days test on vue, I decide the swith to vue, which has massive benifit in terms of performance and memory. The most concern I care about is the observable concept, which also available in vue， with much less memory usage and much more performant.

//ko let observable=ko.observable(1);

let computed=ko.computed(()=>{return observable()+1}); computed.dispose();

let subscription=observable.subscribe(()=>{}); subscription.dispose();

//Vue let ref=Vue.shallowRef(1);

let computed=Vue.computed(()=>{return ref.value+1}); computed.effect.stop();

let watch=Vue.watch(ref,()=>{}); watch.stop();

[NinjaCross]

It seems the conversation is going wildly OT. That's not a good sign, IMHO.

@NinjaCross If you're running into a problem, please let us know. There are still people active on here, the Google group, or on StackOverflow.

I'm in the process of working on a 3.5.2 release with a few bug fixes. Hopefully before the end of the month.

@mbest any news about the release you mentioned here ? https://github.com/knockout/knockout/issues/2564#issuecomment-803654927

Thankyou very much for your effort.

[4skinSkywalker]

Hi guys, I read most of the messages and I want to share my opinion. The debate is the new vs the old, right? I've worked for some time as a web developer (years) and used a lot of technologies (CGIs, SSI, PHP, Joomla, Wordpress, Angular JS, Angular, ...). I enjoyed the ride so far and technologies are much more expressive nowadays. Frameworks with CLIs, Webpack, NPM, browser that support 3D stuff, web components, web workers, PWA etc... Yet with all this power you can still be, if not more than before, frustrated. As an Angular dev I have to complain about its errors, those are the weirdest thing ever: errors that don't tell anything about the error itself. What is catched at compile time is pretty clear, but runtime errors are completely unintelligible: it's like Angular is complaining about the quality of water in Turkmenistan for no apparent reason. Another thing that is disturbing is migrating between versions. Currently I'm writing code for an Angular 12 dapp and I recently migrated to it from Angular 10. I had to lose a couple of days just to fix stuff: the migration guide didn't have everything it was supposed to have for a smooth migration. I needed to migrate because a library I needed wasn't compatible with the TS compiler I had in my dependencies, and I couldn't update just that, because the CLI or something else was giving me boundaries on versions I could install. A nightmare. But, everything went fine. Now I have less functionalities (Webpack 5 has no polyfill for Node.js methods) and less performances (compile time increased substantially). It remainds me that time my old, but perfectly working, iPad 1 couldn't update the fucking calculator because it couldn't install the API required by it on the app store. Come on, it's a fucking calculator. The Commodore Amiga can run it without even having the notion of API! That said I think Knockout is beautiful and it's a good choice when you want something with which you can start fiddling right away, just by importing a script in your index.html.

[NinjaCross]

I realize the conversation is continuing to go OT. I asked multiple times @mbest for info about the next release, but without feedback. I see no reason to keep this conversation alive anymore.

[mw44118]

i still use knockout after what I believe is 10 years or so, i find no other library that provides the same support. I've even created variants of knockout for languages like Lua since it works very well for a broad range of problems

I'd be very interested in reading this code or at least understanding how you wrote it. I barely understand ko internals and reading a different implementation might help me understand the ideas better.

[darwinva97]

So... Do you have any problems getting knockout js programmers in your companies?

[groovenectar]

So... Do you have any problems getting knockout js programmers in your companies?

I am for hire and I appreciate KnockoutJS...