Knockout.js Future (2017 and beyond)

[smort...@wakefly.com]

Hi,

* Please answer to this question if you are part of the creation team. 

I have seen old same questions, but let's bring it up again for 2017 and after. 

By looking at the history of commits, there is a long gap from January 2016 to December 2016, so, after I was convinced Knockout.js is dead, bug fixes and updates start getting committed from Dec. again.

So, please give us an honest answer, is Knockout going to die in near future? What are the plans for adding new features and keep it updated?

I would like to use Knockout over Angular, in many cases, because of it's agility and being focused on data binding. But, I just want to use Knockout, if it is not a dead framework!

Please let us know.

Thanks,

Sia

[Michael Best]

It's definitely not dead. Thanks for using and supporting Knockout.

[smort...@wakefly.com]

Thank you Michael for your reply.

Still, I wish we could hear more on Knockout.js future and roadmap, especially relative to other similar frameworks.

[Antonios Liakakis]

Hello,

Indeed a valid question but just wanted to point out that Knockout is being used although sometimes not mentioned in various sites. Granted there are issues open and some are not being fixed but I haven't seen the severity of them. If there is no breaking issue bug I have to admit that Knockout is among the most stable libraries for many years and it supported concepts e.g. components, before React came into the scene. Nevertheless, bug fixing would show some continuity for the library which would be a safer choice.

[smort...@wakefly.com]

Antonios,

Thanks for your reply, but I think bug-fixing is not the best indication of framework future. 

My question is more about, for example, "What will be the status of Knockout.js in 2020, individually and related to other similar frameworks?"

Will the answer be "It will be one of the main competitors in front end frameworks and a few major versions will be released from 2017 to 2020"?

Or, the answer will be "The version will be what is already in 2017, but all/most of bugs have been removed"?

In the later case, I think I don't want to learn and use Knouckout.js, but for the first answer, I would definitely go for it. 

I hope what I'm trying to say makes sense.

[Antonios Liakakis]

Unfortunately it is very difficult to predict the future of FE frameworks especially this time around http://stateofjs.com/2016/frontend/

Currently React is more or less in the lead but its usage is complementing already established sites. Do not select a framework based on the popularity. Learn Javascript and then any framework will do. Because each lib/framework solves a specific problem and in the end it all comes down to team experience (if there is a team present). In my last project I used jquery and knockout because the team was mainly BE developers with some FE experience with jquery therefore the most reasonable was to use a lib close to jquery's dev style.

In other words do not select any lib/framework based on hype. What happens if in two years time React is obsolete like Angular 1.x ;-)

[smort...@wakefly.com]

Antonios, thanks for your reply. :-)

[Cameron Macintosh]

Hello Michael,

Perhaps a better question is: can the maintainers publish a (rough) roadmap of what they'd like to achieve in 2017?  I get that schedules are more fluid with open source projects, but knowing if we the public can expect just bug fix releases or a new version release would be nice. Additionally, how can interested users of ko help with getting releases out the door.  

Additionally, some sort of "How to contribute and get involved" documentation (and supported culture) is, in my opinion, sorely lacking and is something I miss coming from other framework communities.  I, for one, am always looking for open source communities to get more involved in and would love to contribute, but this unsupported contributor culture is a bit of a barrier to entry.

I've found that these two things pair well together and help lend to the sense that a project is alive, well, and moving forward.

Respectfully,

Cameron

[Michael Best]

Take a look at https://github.com/knockout/knockout/milestone/9 and https://github.com/knockout/knockout/issues/1932

-- Michael

[noirabys]

Hi,

 when will milestone 3.5 be released ?

 knockout is pretty cool, but there is one feature missing which prevents an object oriented approach without ugly workarounds, which 

is when loading persistent objects from ajax, for example a list of countries objects and i've a select box with one country object selected, the comparisson

works on object identity since it's loaded from persistent state the country object in the list is not the same than the selected country object.

it would be great if an identity function could be specified,

i think there is a bug entry which is tagged 3.5 milestone ... 

thanks for any informations on that topic,

   noirabys

[Jorge Rimblas]

One thing that gave me comfort in my decision to use KnockoutJS is that Oracle JET uses it.  Visit oraclejet.org and check out the cookbook.

Oracle put significant effort into this toolkit (they don't call it a framework) and it's all on top of KnockoutJS.

Without KO there's not JET so if there are support issues that may arise, I can see the JET team stepping up.

Does that matter? You decide.  In my case, I say it definitely does.

[noirabys]

Hi,

thanks didn't know oraclejet, but looks nice :-)

[smort...@wakefly.com]

Hi Jorge,

Thanks for pointing this out, but I'm afraid OracleJet switch to another framework in near future. 

I'm not really aware of such a thing, I just mean this doesn't guarantee that KO will be an active library in the future. 

In the link provided by Antonios, http://stateofjs.com/2016/frontend/, KO is already marked as legacy!

[Gunnar Liljas]

The entire Azure portal is also made using Knockout. It's a horrible mess, but that's now Knockout's fault.

The desktop application http://storageexplorer.com/ is also built using Knockout (and Electron).

/G

--
You received this message because you are subscribed to the Google Groups "KnockoutJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to knockoutjs+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jorge Rimblas]

Hi, 

Sure, switching OracleJET to a different approach is possible, but not plausible.

The scope of JET is massive and a migration would require a massive undertaking and probably incompatibility with previous versions.  Every single component is a custom binding, they there are many.

But, I don't work for Oracle and don't have inside knowledge. I do work with Oracle products and have learned the JET basics.

[smort...@wakefly.com]

True, Jorge.

Thanks for your input, again. ;-)

Cheers,

Sia

[Lajos Marton]

Hi All,

I see some life in mbest/tko repo. Could you send us some more details about whats next, and when? Or even, can we help in anything about next major version of Knockoutjs?

[Clarence Tunstall]

This may be an old topic but very relevant to me. I'm an old school, full stack developer, from the rooter to the tooter (yes from the country) I've just learned knockout and love it for its data binding and its promise for developing a set of components to dynamically handle complex data structures. These are for my personal projects on which I'm working but at my job, my team leader loves Vue js so I wonder if I'm reluctant to step into the next century of client side programming or is it as I suspect and these new libraries are just not equipped to handle my development needs.


Most popular doesn't mean better
As someone already said, but I see the popularity of React and Angular (although less now than a year ago). Neither of which do I know, but I've been trying to discover the reason for their popularity and if it fits what I want to do. If I use Angular I may as well forget about using .Net MVC except to build an API that my Angular code would consume which isn't a bad idea. But if I want to get my products out as soon as possible should I embark on the learning curve required to build the dynamic tools I need for my projects using Angular and its host of accompanying libraries, converters, server generators and transpilers... not to mention its own library which seem humongous. React and Vue (my boss' favorite) both seem to lack the data binding I need for my complex data structures. I'm going to have to learn Vue for my job and am in the process of doing so, but find myself have to try to find reasons to like it... with knockout it was instant.. I was loved it from the start and continue to, but am afraid that it could be gone, especially considering the fact that object.observable() is being retracted. But its lightweight, highly extendable, and very practical for creating components.

What the hell is so complex about my data?
My data isn't any more special than anyone else's but some of it is used to manage the properties of the websites. There are objects within objects several layers down, some with object arrays and some with enumerators and constant values. With Vue, I'm still trying to discover how to load my data separately from my instantiation of a Vue object and it hasn't worked yet. With knockout, I go back and forth to the server as I need to and can load data when I want and watch the table rows appear, or the tree levels get added and extended and it matches my data. So if I want to update a portion of that data, bound to element via its component, its been very stout at updating the object behind it (as does Vue and I imagine every other library), and I can very easily use methods within that component to update my back end database as I please. My projects aren't about displaying some hot new set of graphics with endless bells and whistles that make it so wonderful, its about number crunching health care membership data, its accompanying EDI transactions all while handling a constant stream of data and its auditing mechanisms going back and forth to update multiple data sources, users and nodes using ajax and duplex communication. 

What Started all of this?
I was trying to build a dynamic table using Vue and it will not render because the data is loaded via Ajax after the pag is loaded... With knockout, I set it, then bind it and the table appears... with Vue I'm still trying to figure it out and then in their documentation  under the header "Change Detection Caveats" I read this:

"...Due to the limitations of modern JavaScript (and the abandonment of Object.observe), Vue cannot detect property addition or deletion. Since Vue performs the getter/setter conversion process during instance initialization, a property must be present in the data object in order for Vue to convert it and make it reactive..."

and my world stop. First, and unless I miss my guess, suggest I cannot dynamically create properties which means I have to define objects inside Vue with data values which explains why my table isn't rendering... but and here's where the world momentarily stopped spinning, said abandonment of "Object.observe". Isn't that on what knockout is based? Is knockout about to die? Then research led me to a page where it said that I should not base any new development on "Object.observe" because it is obsolete. My searches on the condition of knockout has led me here and while I am drawing a cautious sigh of relief, I have to learn if this means knockout must die because the technology on which I always though it was based is about to die.

My Rant!

I just started using knockout js and love it mainly because of its databinding and the ability to extend the bindinghandlers and create components utilizing templates. I don't want to see knockout go because out of all of the other libraries it seems to be the only one that is based on data binding. That's. What. I. Need. I don't need routing... yet.... and when I do, I have .Net for that (however, client side routing with .Net Core 2 based API does sound intriguing... very intriguing). I don't need a virtual DOM (hell I can create that using basic JavaScript object variables!). Unless browsers covert to it, I don't need ES6 although I wish they would convert to it because it's just so powerful. I definitely don't need transpilers, bundlers, application structure generators or Grunt to run my JavaScript tasks as some sort of quasi server. Also don't need to be told how to code my objects or when to code my objects or when to make them available to make it easier for the next programmer to read.  I need something that can, out of the box, handle my data or at least provide me the mechanism to do so without hacking through their code. If I gotta hack, its outta wack... I just made that up and I'm sticking with it.

My experience thus far with Vuejs
Now, I'm just learning Vue but even its own documentation says it can't do what I need. Apparantly, I'd have to use coding constructs of ES6, then a transpiler to convert it back to ES5 just to accomplish what that in which knockout specializes. Right now, my table is flowing through its for loop to load and its documentation seems to suggest it won't unless I load the data before I initialize the Vue object... the end result is my table isn't loading after the rendering. It appears to still consider the array object to be as empty as it was when it was initialized (per their instructions). With knockout, I bind it and I'm good. I disappointed to discover that I'll have to add multiple layers of black boxes on to my projects just to create some javaScript. I thought Angular was very nice, but again, there's so much extra stuff to add to the learning curve to get it going. Vue seems to be its kid brother. Its taboo to suggest adding a link to the library, referencing it and keeping it moving. I've got to have an entire new system on which to build the application structure. As a .Net programming I already have a solution that's doing that. Plus, since browsers seem reluctant to step into ES6, I've got to have bundlers and transpilers and grandma's special sauce just to develop my application. and its all overhead to my code. Its like JavaScript, HTML and CSS is being made overly complex to solve a problem that doesn't exist. 

Irregardless is still not a word, but... Irregardless

No matter how you slice it, I'm going to have to learn and use Vue because my job requires it and that's cool. I'll use what they want, hell in the end it can only help me. But for my personal projects, as a full stack developer I need to use knockout and I need to know its going to survive this observable retraction. To my knowledge thus far, it gives me the greatest flexibility to create my own library of complex components, to handle complex data structures that I'm discovering libraries like Vue Js, may require tons of extra programming to handle, but again... after all of that I ask, is it still going to be there when I need it or is there some FBI conspiracy to get rid of it... how can it survive without object.observable or... please God let it be so, am I wrong on it being based on it in the first place. 

[Michael Best]

The short answer is that Knockout doesn't use Object.observe. There is absolutely no reason for Knockout to stop working,

[Trygve]

We started developing solutions with Knockout in 2012 and those solutions are alive and well and serving a lot of happy customers every day. So no, Knockout is far from dead. Actually, it is probably both the easiest to learn and also the most stable data-binding "framework" (I actually consider KO a library, not a framework, which is one of it's strengths IMHO). After moving to typescript and KO modules, our code is very clean and with excellent separation of concerns. KO sure has it's tricks and issues that you need to be aware of, especially the mapping plugin has caused a lot of grief until we figured out exactly what happens behind the scenes and how to use it correctly (always initialize the mapping with an empty viewmodel skeleton with all nested objects and array objects set).

Also, once you understand the true nature of two-way databinding and how to optimize performance with .extend({ rateLimit: { timeout: 20, method: "notifyWhenChangesStop" } }); it performs really, really well.

We still haven't found a reason to abandon KO for a more modern framework that does more or less the same thing. It would be totally hopeless form a business/developer productivity perspective. What we are anticipating for the next breakthrough for web development is WebAssembly and the Blazor project in particular. Blazor is created by Steve Sanderson who created KO back in the day.

[Lajos Marton]

Hi Clarence,

I'm a ko lover, but novadays I moved to vuejs. Partially you are right, knockoutjs is the best simple data-binding lib even in 2018. But why I'm writing to you, vue is minimum as good as ko, even better in lots of things. For example you are not right when you wrote vue needs ES6 and transpiling code. You can use vue as knockout and write your code in ES5 (actually I'm writing my ko code in ES6-7).

And you aren't right when wrote that vue can't handle complex objects. It can handle, and it is extensible as well. On the other side vuejs is very component based, so you need a bit more careful to create you components, then in knockoutjs.