What is the future of knockoutJS?

[grindcore819]

What will be the future devs that will be made on KOJS? I just want to know if it's worth it to use KOJS to develop my future web apps.

[cervengoc]

If you like the concept of knockoutjs, it's definitely worth it in my opinion. I think KnockoutJS is fairly complete in its current state, I see only some minor new nice-to-have features.

My personal preference after some years of experience is to use lower-level frameworks like KnockoutJS which doesn't want to tell you how to build your application, just gives you a help in that. Of course I'm not telling here that those nowadays more trendy robust frameworks like Angular are bad in any sense, it's really just a personal preference.

[grindcore819]

Ok, then why aren't they pushing anything new?

[chrisknoll]

The last release (3.4.0) was about 7 months ago, and so we're due for another release. There's been 20 commits to master since this release, so we'll likely see another release soon. In fact this link: #2001 points to the 3.4.1 release notes. So, the'll be pushing new stuff soon.

As for the 'new stuff' I don't know the roadmap, but there's things that could be done (there's 104 pull requests in the repo). and as ES6 gets more adopted and the latest javasript advances become more mainstream, there will be more opportunities to update the core. But for now, it has very sold dependency tracking, templates, components and a very extensible databinding framework. I'd wager that most of the advancements in the KO space is through the notion of custom bindings not enhancments tot he core. @cervengoc has it right: KO doesn't force you down a specfic path like larger frameworks do, so that gives you the flexibility to plug in the elements of SPAs that you're most familiar with (such as a security layer, routing, module loaders, etc...all of this is up to you to decide). Or if you are just starting in the space, don't bog yourself down with learning 10 technologies at once. Pull in the core, set up a simple app, and learn how to extend it.

In fact, if you have not run through their absolutely amazing tutorial here:
http://learn.knockoutjs.com/#/?tutorial=intro

I highly recommend you try it out. It covers the essentials for starting to use the library, and if it doesn't blow your mind, then you're probably not looking for anything KO has to offer.

[IanYates]

👍 for the thoughts from @chrisknoll and @cervengoc
I'm in the same camp.

[caseyWebb]

You may be interested in https://github.com/knockout/tko

[m-rakic]

I think KnockoutJS has a future. Few word as KnockoutJS I'm using it since 2.0 and I'm using now 3.4 and all power of web components. The main essence is that KnockoutJS is a library and tend to be that this means that you need to learn other technology to made complete application.

First what you will need is library for rooting if you want to start on SPA. KnockoutJS give you a flexibility to make your own patterns the way you will build the application. So you have to find the right ones to make your application succeed. I think you can find a lot of examples by google it.

Bigger frameworks/platform like Angular 2 tend to give you a patterns and paths to build a application that will work out. Gives you a examples of all application live cycle from building, deploying and testing. The focus is not in one bit of application but all aspects.

In our example we was working with MVC .NET, application was doing ajax calls and updated divs. We used a KnockoutJS to bind some forms. Our decision to move from updating divs to templates and web components reduced the rendering and loading because was just loaded data and rendered peaces need to be rendered. Except that performance improvement data bindings and templates reduced our code 2 to 3 times. This is the case where KnockoutJS shine.

Be aware which kind of project you want to build if you want to build public sites or web applications with no need with search optimizations. Usually for public sites is used server side rendering, data binding systems is not friendly with search engines.

[aggrhm]

Just wanted to reinforce what's been said: people should view this library like they view jQuery. KO sets out to do a specific set of things well and that's it. Anything more than that will become overly opinionated. Furthermore, the addition of KO components allows me to do pretty much anything any other framework can do; I really don't expect much from future releases other than performance tweaks, bug fixes, API improvements, etc.

That being said, I could see the KO.punches extension by @mbest merged into the core at some level. But this is just syntactic sugar on top of existing functionality.

[Dmitri-Sintsov]

I also use knockout.js in a large enough project. Not only small size of library and not enforcing of specific patters attracts me, but also complete possibility to develop in ES5 without transpilers.

But ko.punches should not be included into the core, because using curly braces is semantically alien feature to html. data-bind html5 attributes with JSON as values are very organic and semantically proper ways to define bindings. If one wants short bindings then there should be custom tags used instead, not curly braces.

It is especially important feature when knockout.js templates are inserted into server-side templates, most of these already use double curly braces in their syntax so there will be syntax clash / the need to escape fragments of ko templates in such case. While data-bind attributes with JSON values are compatible to any server-side templating because they are not alien to HTML syntax.

It is strange why knockout.js is so little popular, it's hugely underrated in my opinion. Vue.js is not better than knockout for example. They stick binding to their own class, which makes extension of viewmodel classes difficult, while in knockout any Javascript class can be bound. React / Angular is another story, they are huge and use transpilers.

Sadly but everything is ruled by market and when something is low-demand then people tend to avoid it, even if that is a good tech like knockout.js.

[nkosi23]

We only develop large scale single page applications (100+ views), and use Knockout everywhere, and plan to continue to use knockout everywhere at least for the next decade and probably for the following two.

We do not use Angular / React etc. Only Knockout + a routing library, + a set of 50 or so HTML/Javascript widgets from a vendor. This is enough to meet all our needs and our clients are baffled by how modern and fast our applications are.

Frameworks come and go, but Knockout is still here. Because it focuses on solving the problem with technical elegance and no unnecessary hype. There is a huge community behind it, and there is no reason not to use if you want to develop modern and composable user interfaces.

And considering the maturity, the stability and the community of Knockout, the question shouldn't be : is it worth to use KOJS, but why even use something else when such a lightweight, flexible and efficient solution exists ?

I can only agree with Dmitri when he says that knockout is underrated. But one of the most important skills in Software Development is the ability to ignore ratings and use your own brain.

[brianmhunt]

Incidentally, somewhat related — TKO is in Alpha-3 now. I'd be interested in feedback on it in general, particularly as a drop-in replacement (i.e. backwards compat.) with ko 3.4 in large-scale apps. Thanks in advance.

[nkosi23]

I'll definitely give it a try ! We are in a launch period these days so a bit overbooked, but I'll definitely give it a try by the end of August and will tell you our experience in the TKO repository.

[BooleT37]

In my opinion to ensure the future for knockout.js it's absolutely crucual to have it get along with mordern front-end features like modules (commonjs, not AMD), splitting code to reusable importable components and webpack. You can't use knockout with webpack now, webpack disrespects any global variables and knockout still sets the ko variable to window object. The knockout-validation project just breaks when using with webpack (the issue is in "use strict" statement which webpack preceedes to all its modules, and rightly so, but it completely breaks knockout-validation; I wanted to file and issue there, but the library seems to be completely abandoned by now). Any modules that extend knockout have to extend the global ko object in window. Webpack goes against this approach as well. These are just three resent issues I've resently put up with, I'm sure there're more.

I won't go into listing webpack's advantages, it's just stupid to have a standaolne library nowadays that does not work with world's top 1 bundler/builder for standalone libraries. As long as knockout will continue to ignore the developements of front-end environment, I will never use in in any of my new projects, the advantages just don't worth it.

[achillesfroes]

There are two types of software projects, those that are delivered and those that are not delivered. As long as the knockouts help me deliver my projects, I will continue to use it.

[brianmhunt]

@BooleT37 Indeed. Modularization is why I rewrote Knockout as TKO with ES6 modules.

[BooleT37]

@brianmhunt I'll look into your project. It looks just like the thing I need.

[ZoranPavlovic]

@BooleT37 I use Knockout, and Knockout-validation in conjunction with webpack. They work just fine together.

[WhereJuly]

Isn't Webpack operates well with AMD and window globals?
Webpack's:

• Authoring libraries,
• externalize library,
• expose window global variables,
• engage AMD modules

[WhereJuly]

I agree 100% with the guys above telling the praise to Knockout. From a beginner perspectve Knockout is a breeze to start. It is as natural as writing HTML and as powerful as probably Vue in its core (guessing here as I only read a couple of books on Vue). Yet it helps you to establish the correct OOP habits in JS. And finally it completelly allowed me to get rid of heavily annoying querySelector and event listeners things, i.e. decouple views from models. I switched to pure JS / no Jquery roughly a year ago and had a fun tough :) time writing long lines. Knockout just freed me up and gave so much more power. And it is only 25kB.

[Dmitri-Sintsov]

Vue uses it's own instances for binding - AFAIK one cannot use arbitrary class instance for binding - they use new Vue() or Vue.extend() to create bound instances. It is inflexible and makes more difficult to reuse the code. While in knockout.js I could bind to almost any class instance - from simple object to extended (pseudo-inherited) external library class.

Also when comparing react samples and knockout samples, later ones are usually shorter / cleaner. The only downside is they tell that react is faster due to virtual DOM and due to more verbosity.

Knockout is underrated, although probably can be developed further (virtual DOM support? eg https://github.com/Olical/react-faux-dom). It seems that Google / Facebook push their libraries much more throughly / aggressively than Microsoft.

[WhereJuly]

As for performance I realy do not see an issue for Knockout (though I am quite an inexperienced so far).
Accorrding to the figures at the link below, adding 1000 <li> items to the page is 0.39 sec for KO and 0.19 sec for Vue.

I cannot imagine a general person can ever manage to visually absorb the info in 200 lines. Let alone 1000. So basically one can speak about difference between 0.08 sec and 0.04 sec. This is how much KO is slower than Vue at generation 200 lines lists. Far below the human recognition speed.

Here is the comparison table, React there as well with approx. the same figures, a bit slower than Vue.

So in practice I do not see how one can say Vue (or React) is faster then Knockout.

[mbest]

@Dmitri-Sintsov Knockout isn't a Microsoft library. It's entirely independent.

[chrisknoll]

So, I looked at the benchmark @WhereJuly referenced and the source code for the benchmark, and the one item that really stood out was appending 1k rows to a 10k table (Otherwise the numbers were comparable)...the chunk of code that did it was this:

    self.add = function () {
        startMeasure("add");
        ko.utils.arrayPushAll(self.data, buildData(1000));
        stopMeasure();
    };

This looks proper enough, tho an alternative that I think i would have done is:

    self.add = function () {
        startMeasure("add");
        self.data(self.data().concat(buildData(1000)));
        stopMeasure();
    };

I'm not sure if pushAll on an observable array signals individual update notifications or if only will send 1 update with the bunch of new rows. Secondly, I don't know if the foreach binding will take the bulk of items that was pushed into the array and append to the end of the DOM or regenerate the entire dom over again. There does seem to be something amiss here tho because the timing of 4734.22 (assuming ms) is really out of wack compared to the other timings, and considering it takes 380ms to create 1k rows (from the first test) I'm surprised that the pushAll() on the observable array just didn't result in creating 1k new row elements in the dom, it looks like it's being completely re-rendered (or maybe each row is being individually rendered instead of a bulk insert).

I don't mean to hijack this thread to dive into this benchmark maybe this is something that can be investigated separately, just wanted to bring it up to anyone who wants to see about the reason why there's this big skew of timings in this one case.

[mbest]

@chrisknoll ko.utils.arrayPushAll wasn't meant to be used with an observable array, but perhaps it's an improvement we can make. For now, I've reported this: krausest/js-framework-benchmark#256

[louiedgomez]

I'm still using knockout..

[ghost]

I just started using it now.

[brianmhunt]

I posted an answer here that might give some insight, too: #2374

[eriksimonic]

We are using it for around 2+ years now and it works without a hitch.
We are using it in small project but we are using it for main UI management solution in a big project.

[nkosi23]

@avickers thanks for your reply, even though I was mainly addressing @agquick to be honest, but I am grateful for your insight.

Only referring to your reply, I am totally in line with your message, and this is exactly what I have been saying but maybe it wasn't clear enough. One thing you made me realize is that there may be a misunderstanding here, when I talk about marketing, I do not talk about marketing budgets and running ads. The truth is all the points you mention fall into the marketing category. And this is by the way part of what I was trying to convey.

Because sure it is possible to address them with a technical focus, but the gist of my contribution, was to suggest looking at these challenges from a marketing angle. Because unless you do that, - for example - when it comes to answering: what is the right amount of opinion? You are back to square one, because there is no purely technical answer to that.

The marketing I referred to has nothing to do, with advertising and marketing budgets etc. This is marketing in its broadest sense: approach to market.

[nkosi23]

As far as the UI framework is concerned, (I think - personal contribution) this is exactly the type of things we need, but as @cosmoKenney said, I also think that this is exactly the type of thing that should be implemented as a plugin.

The framework you are working on is cute, I wouldn't use it personally because I have the same mindset than @cosmoKenney on that one, but I can see that many people would (angular-minded guys and such).

My point of view is that the only challenge ko has is an education challenge. Initially ko had a full blown marketing challenge, but I think tko has provided the right technological framework to the technical part of this marketing challenge. Now what's left is the education part. And education is more than writing docs and wikis, it is about how to convey your value proposition considering the mindset/background of the market. And it starts with how you package your value proposition, what is the stuff that people see (and that you therefore need to explain).

My feeling is that as far as technical matters are concerned, even though Brian put the horses before the carts (as he puts it), he got it 100% right. I think tko is the technological backbone we needed. It is delivering on the vision we have all expressed in this thread, and it does so by providing an elegant and consistent framework. It even plans for opt-in NPM support and such toolings, thus providing vue/react/angular enthusiasts a path to do things the way they like, from knockout-contrib's upcoming NPM repository all the way to ko-core. People will be able to NPM their way to ko and its plugins and enjoy dependency-management and similar hand holding.

So I think at this point, the only challenge we have left is being compelling with the way we package ko and present and explain this ecosystem to the world. Packaging is part of education, this is even the first step of education (one which is often overlooked and not optimized enough).

I would therefore suggest the following action plan:

1. starting by surveying the current ko plugins (even old and unmaintained ones), to see what we've got.
2. Identify the most useful/and or promising ones that are worth refreshing (as far as tooling / build suite is concerned), and invest some modest resources to get them both tko-ready, and npm-ready
3. Look into how we can mix them, combine them, and pre- configure them to create development experiences accomodating different styles, preferences and needs. (Single page applications, react-style, angular-style, light script added to server rendered page etc...). Each of these pre-packaged and pre-configured flavours will be marketed as "frameworks" offering a particular out-of-the-box development experience. People will choose the one best accomodating their preferences, and power users are free to ignore this hand-holding. This is also where and how hype-driven framework will be able to emerge to keep ko sexy.
4. From that point, we'll be able to see, where and if a new plugin, such as the one mentioned in the messages just before should be prioritized to complete the ecosystem picture before announcing tko to the world
5. Then, once all the backbones are in place, we can focus on the communication part: writing missing documentations etc... for plugins, and the overall frameworks/development experiences so that newcomers have all the information they need in one place and perceive maturity.
6. And once this technological backbone is there, we can create the plugin exploration website, having one part presenting various framework flavors (plugins pre-packaged and pre-configured to propose a certain experience), and another part focused on individidual plugin discovery.

This is what I would suggest. It builds on the existing. It minimizes the manpower needed for tko-core since it relies on plugins, it preserves flexibility for mature power users by making all the toolings and such opt-in at a low-level (which really is a feature of tko), and it does so while accomodating the vision expressed in this thread.

Is there a consensus on this proposal?

[aggrhm]

Hi @nkosi23, sorry, busy week. I’m on board with tko. A UI framework should without question be a separate plugin. My only question for tko will be how much friction it takes to get started with a basic app ready to go. I really like the CLI prompt that @cosmoKenney mentioned for prompting for initial setup with sane defaults. Maybe as time passes we see which packages become most frequently used and suggest those by default, so that when I’m done with the CLI create-tko-project process I’m ready to start coding.

Ultimately I think people will be pretty opinionated about what a “starter” tko project looks like, so it would be cool if I could host a JSON file or something that specifies the defaults for the CLI create-tko-project tool. Then people could just point to that to initialize their project.

I believe tko could bring people back to Knockout as long as 1) it’s easy to see which plugins are most popular, and 2) the create-tko-project tool decides on some defaults that get people started quickly. It may have to be a little opinionated but it’s okay because it can be overridden.

[avickers]

Thanks for the detailed feedback, @nkosi23.

The framework you are working on is cute, I wouldn't use it personally because I have the same mindset than @cosmoKenney on that one, but I can see that many people would (angular-minded guys and such).

This is, more or less, what I'm going for. I understand that the people that like the sort of things that I'm working on have already migrated to the popular frameworks with large communities. The people left here are going to be the ones that don't value such things as much. As such, responses that ranged from studied indifference to mild hostility would be what I would expect. 😁

I think we have similar viewpoints, and you're right about education. The website themselves (knockoutjs.com / tko.io) are certainly a big part of it; however, I have been thinking more about how to be able to "market" KO effectively in 15-20 minutes--the amount of time someone might get to make a presentation at a local Meetup or in a quick introductory video on YouTube.

I was forced to quit using KO last year. In order to help decide whether to move to React or Vue, I found YouTube playlists showing someone making reasonably complex applications over 2-4 hours of video playlists. (Everything looks good for making a Todo List...) In the ones that were done well, each video was between 5-30 minutes and covered a specific concept. It was usually easy to follow along without needing to pause to carefully study what they were writing or consult the documentation. If they cut and pasted anything other than simulated back-end data, I quit watching.

So, I've been thinking about what it would take to make a similarly compelling series for a KO app. The objective being to produce a decently complex and professional looking project in just a few hours, while also providing a 🐸 in the pot of boiling water experience.

If the community wants to be successful in bringing in greenhorns, I think it's important that we consider how to effectively sell the advantages quickly and cleanly by way of complete examples that would be easy for even novice developers to replicate on their own.

I feel that there's a lot of people that won't be willing to spend an hour reading the documentation on a website, unless they are first hooked. YouTube and Medium are probably critical channels.

The CLI tool seems mission critical, so hopefully Ken and Casey will do great things! (No pressure. 🎈 )

[ryios]

Does knockout currently have any good plugins for Hash Fragment Syncing? I tried a few and they were all kind of lacking....

I've built one for an app recently and run into a lot of things I had to fix with it, so now I'm leaning towards version 2:

• support running in Dictator Mode or Cooperative Mode (dictator mode, the hashSync plugin owns the hash entirely, nothing else can use the hash fragments. Cooperative mode the hashSync plugin stores all it's key value pairs inside of a single key value pair that can play nicely with other things using hash fragments.

• support for hash change event with added/deleted/changed/not change tracking.

In other words if a value is added it fires an event for that hash fragment as being a new hash fragment that wasn't there before. Or if a hash fragment that was there is no longer present then it fires a delete change etc.

The plugin will work via an extender, so you can extend an observable to add it to the hashSync plugin, i.e.

var viewName = ko.observable('grid').extend({hashSync: { key: 'view' });

I'm actually considering creating a new observable type specifically for hash fragment data and getting away from the extender concept that way you can create a fragmentObservable and have it so you can send a complex object into it and have it track all of those values.

The plugin would have to be initialized to Dictator or Cooperative mode and in Dictator mode you'd only have one fragmentObservable per application.

I'm tinkering on it, I might change how I want to implement it, but I have an SPA that is 100% driven by it's hash fragment in real time with full support for back/forward navigation and deep linking, so I want to transition that logic to some kind of knockout plugin.

[avickers]

You're not worried about the implications of new privacy laws in the EU/California vis-a-vis storing application state/user data in the very public URL?

[caseyWebb]

@ryios I think you might be describing something similar to the Query package in my knockout-contrib repo

[ryios]

If storing state data violates GDPR then how does any app in a browser maintain state?
Amazon stores a load of stuff in the url....

I don't store user data in the url, I store state data in the url, like what sort is active, what search word is being search for, and whether a view is in grid mode or row mode, etc etc.

So that browser navigation works through the SPA's state.

I actually have it working super well rolling my own hash Sync plugin for knockout from scratch, it's just a chore to use atm.

i.e. I can do this

    var viewName = ko.observable(null).extend({
        hashSync: {
            key: 'view',
            preChange: function (newValue, changeData) {
                changeData.view = true;
                return newValue;
            },
            postChange: function (newValue, changeData) {
            }
        }
    });
    model.viewName = viewName;

To kick it off, I call

ko.hashSync.initialize();

and you can subcribe to a hashChange event via

ko.hashSync.addHashChangeCallBack(function (viewFragments, changeData) {
//
});

When the callback fires it tells you what keys in the hash fragment changed from their previous values and the preChange event can be used to override a change etc.

Now the issue I ran into was sometimes I needed to change 3 hash values in one user action (like searching for text with a sort in one move) so it was causing to browser push states to occur. So I made updating the extended observables not trigger a hash Change event.

You have to manually call

ko.hashSync.updateHash();

When you're done updating your values.

[navkirat]

Lol, where does knockout fail? Should we not be innovating when a technology fails? It is a library and not a framework and I see where that could be the issue for a SPA. But, for a MVC app, I think knockout, knocks the pants off other libraries!

And Isn't the whole idea to reach the market faster? Best value in the least amount of time?

[NetLancer]

where does knockout fail?

Simply to me it has distinct benefits (data oriented pages, line-of-business apps ..) and good enough browser support make it worth to take with.
I wonder if - apart from well decreased popularity - anyone knows its bad/weak points so far?

[ryios]

Lol, where does knockout fail? Should we not be innovating when a technology fails? It is a library and not a framework and I see where that could be the issue for a SPA. But, for a MVC app, I think knockout, knocks the pants off other libraries!

And Isn't the whole idea to reach the market faster? Best value in the least amount of time?

We just launched a successfull SPA in July with full GTM analytics tracking with over 6000 returning unique hits per day (in the first month) with an 85% returning visitor count. It's built entirely on Knockout Js.

It took us three months to build and the content was generated (300+ articles ) by 2 team members in one month.

Unfortunately it's for an online college so without being a registered student you can't see it.

The build was done in Node.js using Gulp 3 and the application compiles to two JS files (xyz.app.js and xyz.app.vendor.js)

It's straight ES 5, no ES 6, and is segregated into nice easy to edit html templates and separate JS files.

The backend is two sets of rest apis, one is ours for retrieving our content and the other runs on the Google Cloud Platform and is our indexing/search service.

The gulp build puts it all together into a single output.

The app itself is basically a giant search driven experience where we surface all of our content to an SPA with lots of navigation features. We basically built a front end for our content that's driven by search functions.

We're in the process of moving it to Elastic Search because Google Compute's app engine lacks the search flexibility we desire.

I'm currently working on moving it to gulp 4 and using gulp-current-branch to setup feature based outputs of the application so we can easily spin up 20+ front ends for each Git Branch for all the different feature requests.

I.e.

git worktree add ../new-branch-here new-branch-here

Then when running

`gulp complete-compile' in that branch, the current branch name will be used via a gulp token plugin to generate api urls for the branch the build is being run from.

Already has gulp-live-reload setup and makes it super easy to work on locally.

I'm still perfecting the build strategy, but it's pretty slick and it's as easy to work on as any other js framework.

[Dmitri-Sintsov]

I also like very much that Knockout allows to develop in ES5 in pure browser (no node.js) easily. Because ES5 development in React is the hell, while Angular does not support it at all. From modern frameworks Vue.js also works nicely in pure ES5, I think Knockout could borrow some concepts from it.

[zemian]

For folks who is looking for reusable UI components built on top of KnockoutJS, checkout Oracle JET library (it's open source!). They have a live Cookbook full of demos.

I even did some comparison examples between Oracle JET and VueJS libraries.

[miellaby]

@zemian The support of KnockoutJS in Oracle JET is weird. It looks like it's done by people who just want to do old school JQuery UI and borrow KnockoutJS only for component integration.

The documentation highlights big lists of events than a dev should NOT use if he wants to honor the philosophy of MMVC applications where the view depends on the model and not the contrary.

Comparatively the support of observables is minimal. Support of observableArrays as a data source is subpar. Most of the time, adding an item to an obervable array will redraw the whole component. It's even worse with computed used as observable arrays, despite KO having now the ability to emit array-like events from Computed changes as well..

Beside data sources, components settings are generally not observable-complient. No way to define the column schema of a data table with an observable.

I tried to use a couple of components but never manage to make them work well. For the reasons cited above, I got lines duplicated in tables every now and then.

Oracle Jet might be a good framework for some people. But it's definitly not a flagship relatively to Knockout. I definitively don't recommand it to grasp the philosophy of declarative programing with a transparent data-binder like Ko or VueJs.

edit: I did these experiments 3 years ago.

[cosmoKenney]

Haven't looked at this thread for a while.
I had been using knockout for 10 or more years.
But I wanted to have an actual future in web development so I started looking into Angular and React. I tried to like React but cannot get past the jsx syntax. The more I looked into Angular the more I started liking it for a multitude of reasons. For one I can hire Angular guys. Knockout, not so much. Also Angular being a framework makes it easy for devs to stay between the lines so to speak.

One thing I did during my "research" was take one of our web sites and convert it from Knockout + TypeScript + Punches + KO Component Router + TypeScript Dependency Injection (that's the actual name of the library) + KO PostBox + WebPack + Bootstrap to Angular on my own time. It was such and easy conversion that product is now in production as an Angular app.
And our old legacy product with 136 aspx pages is currently being actively converted to Angular.

I really like Knockout binding syntax and flexibility. But juggling several large projects where by the time I get around to doing enhancements on one I end up spending more time upgrading dependencies, or in some cases, downgrading to keep everything working, than I did actual coding of new features. So, I'd love to stay on KO but there are just too many reason to jump ship.

[safizn]

@cosmoKenney Just stumbling upon here, I think in development there shouldn't be any emotional attachment to frameworks, these are only tools. Popular frameworks may do things not the right/best way, but they provide quick solutions. The developer should make an informed decision when to switch. Choosing frameworks with large ecosystem is the fastest track to rapid delivery and keeping up with new trends.
For example, React has virtual DOM, and is incompatible with Web Components (shadow dom, Custom elements, HTML templates, etc.), but building applications with it is very productive, as there are variety of open source components to choose from (just plug and play) with complete design solutions like Material-UI.
Why stick with Knockout when it is dead already.

[Dmitri-Sintsov]

Knockout runs directly in browser ES5 mode, one does not need to install large set of Node.js tools to develop with Knockout, just plain browser page. No TypeScript, no Webpack, no anything. Knockout is a kind of "upgraded jQuery", not a full-size framework. However it covers around 70% of these frameworks features. Knockout has no magic, the observables are just functions.
The one who prefers simple tools and no magic still may use it.

[aggrhm]

I think both @cosmoKenney and @Dmitri-Sintsov are right. I prefer the simplicity of Knockout as a library. I also understand the pain of trying to patch together libraries to make a framework.

I am a huge fan of Knockout but for reasons beyond my control I've had to work on apps built in Vue and React. Vue + Quasar is honestly a breeze to develop in, but I still miss the simplicity of basic observables (esp. outside of components). Mobx is also great, but its integration into Vue seems a bit hacky, and while it's better for React, I'm not a fan of JSX.

My ideal webapp framework would essentially be a merge of Knockout and Vue, meaning:

• single file components like .vue files
• virtual dom support
• keep observables/computeds as first-class objects, instead of forcing them inside a view component

Vue 3 is somewhat headed in this direction, but it still is sort of missing the simplicity of basic js objects with observable and computed properties updating a virtual dom.

If Knockout (or some extension of it) did that well, it would be a realistic option for web development again.

[cosmoKenney]

@myuseringithub Nothing emotional about it, really - other than nestalga. We've been on KO for about 10 years after all.

But angular ticked a lot of boxes for our environment, hence the switch.

And like @agquick I agree with @Dmitri-Sintsov that the simplicity of KO keeps it viable in cases where you don't need a complete application framework. For instance, beside our highly complex and large data intensive sites where we run/will run angular, we also host several sites in WordPress. If I had to build a single page form in WordPress I would strongly consider using KO for binding and data validation in that case.

[nkosi23]

The important point is that Knockout still is a very relevant, very elegant and easy-to-use technological solution. I would even say that Knockout is even ahead when it comes to certain things such as Web Components (native Web Component implementations still have gotchas and the developer story is quite a mess - custom tags vs shadow dom etc... - compared to Knockout's straightforward and consistent approach).

We are neither talking about Cobol (developer shortage) nor Flash (obsolete technological approach). We are talking about a tiny javascript library that continues to be very relevant and easy to use in addition to being powerful.

Now if you are paid to write code for clients and if dealing with other companies' existing codebases is a vast part of your business, since most companies out there follow technological trends it's normal and fine that you feel that Knockout no longer is the best fit for you. However this does not mean that Knockout is all of sudden dead or irrelevant or dying.

This is like switching from using a car with manual transmission to using a car with automatic transmission. Manual transmission is not dying or inferior just because some people switch. Most people use automatic transmission in the US while most people use manual transmission in Europe. Many European people do so out of preference, but many do so because they need more fine-grained control over transmission without having to constantly fight against or tweak the automatic box.

Similarly, there are plenty of people building their own in-house software development frameworks on top of Knockout. This goes from contractors focused on greenfield projects all the way to larger companies who can afford to train a new employee calmly on their internal frameworks for 1 or 2 weeks. As long as the technology is still relevant, elegant and easy to use, there is no problem with that. And Knockout isn't just barely relevant, elegant and easy to use, it is in my opinion still among the best technological solutions even today, and I strongly doubt it will go anywhere.

It is like JQuery, I do not see it dying. JQuery is still being heavily used except that it is usually embedded in these newer frameworks and is not directly used by developers to perform direct DOM manipulations. And with this regard, Knockout is aging even better than JQuery since the way to use Knockout has not changed, it got it right from the beginning. It has strong fundamentals. While Angular 1 was upgrading to Angular 2 with backward-compatibility frictions because they had to change their fundamentals, Knockout has not ever needed to change its fundamentals and won't. And it is in my opinion almost feature complete at this point, especially with the upcoming new version.

So in a gist, I totally understand and accept that the project may no longer be as much useful than it used to be for a number of people, but what I am saying is that as people leave the Knockout ship, there is no need to suggest that this ship needs to be burned.

I think it was about one month ago, while we no longer do contracting for external clients, we quickly developed an application submission system to help one of our longtime partners. The front-end used knockout and allowed file uploads and such. We used computed variables to allow dynamically added fields, an observable to show a progress bar as the files and forms where being uploaded using Ajax and all this kind of basic Knockout features to deliver a rich and modern experience using basic HTML5. It took one of our guys one day to put everything together (both backend and front-end), and the client of our partner was impressed by how interactive, modern and rapid everything was.

The Knockout ship is still needed, useful, relevant and elegant, and its future looks bright.

[avickers]

My ideal webapp framework would essentially be a merge of Knockout and Vue, meaning:

* single file components like .vue files

* virtual dom support

* keep observables/computeds as first-class objects, instead of forcing them inside a view component

If Knockout (or some extension of it) did that well, it would be a realistic option for web development again.

I'm curious what you mean by virtual DOM support and why you feel it would be beneficial.

I have reimplemented KO-style bindings and observables in modern JS on top of the new Web Component standards.

import { Koc } from Knockdown

export default class Route extends Koc {
    constructor(data) {
        super()
        const ko = this.ko()  // alias this.kd()

        this.html`
        <div class="container">
            <h1 data-bind="text: hello"></h1>
        </div>
        `

        this.vm = {
           hello: ko.observable("Hello World")
        }

        ko.applyBindings(this.vm)
    }

    connectedCallback() {
        this.render()
    }

    render() {
        this.css`
            h1 {
                color: blue;
            }
        `
    }
}
customElements.define("rt-home",Route)

One of my core requirements is that using it should require nothing more than installing the library and npm i -D parcel. No webpack configurations or plugins. No need for precompilers like LESS/SASS.

I use a single file component approach, although the library doesn't explicitly require this.

The View Models are encapsulated within the Shadow DOM along with the CSS. You can nest them painlessly.

Since it relies upon template literal interpolation, you can use JS variables in your HTML and CSS, including other Kocs (for html``) and Observables generally speaking.

By leveraging the WC standards, you get fast C++/Rust implementations. I find that you can reduce the amount of JS and CSS you're pushing over the wire by two literal orders of magnitude, which brings obvious (and substantial) performance benefits. (~9kb replacing P/React, ReactDOM, StyledComponents, etc.) The fact that styling is more efficient than just putting a bloated CSS framework in your head is an obvious source of developer pain that I have realized will need to be solved before people actually start using Web Components. That's not a challenge specific to my library. It's a challenge to general adoption of the standards.

I suppose the biggest gotcha is that it's ES6 browsers only. I have always felt like that was a huge objection with the KO community, but if you guys are interested in more approaches and miss KO, I can see about actually typing up proper documentation and making the repo public. Caveat emptor, this isn't a drop-in replacement to Knockout. There are numerous breaking changes, but the core syntax will look very familiar, as you can see.

As for the virtual DOM, I have considered making a special version of the foreach binding that uses it, as a standalone plugin, but otherwise, I can't see that it would do anything other than tank performance for no perfectly good reason. That said, I may be overlooking something.

[karimayachi]

The things that are mentioned frequently in this discussion (unopinionated, simple and lightweight) are not the real value of Knockout IMHO. I think most people here (myself included) really appreciate the fact that it's unopinionated, but I don't think that this will resonate with more than a select group of people. Knockout code is simple and frameworks like React or Angular have a steeper learning curve: true, but they also have tools, CLI's and many resources to get beginners started quickly. As for lightweight: performance is important, but lightweight per se? Anno 2020 where everyone pulls in NPM modules for everything, what are couple of KBs extra? Besides, because of the dependency on JQuery, Knockout really isn't that lightweight. 10 years ago we used JQuery for everything, but now having to include JQuery just for Knockout really doesn't make it lightweight. (I know Knockout works without JQuery, it does however use some optimizations when it's available).

What i do think is the key value of Knockout lies in that I strongly feel separation of concerns (SoC) -and MVVM (with all it's flaws) as a paradigm to implement this- is still the cleanest and easiest to maintain way to program Enterprise applications. And Knockout still is the best library (well, I haven't checked them all) to adhere to this paradigm.

After years and years of trying to get away from spaghetti code, we were on the right track with MVVM (although certainly not perfect) and I do feel the community has circled back to unmanageable code in recent years.

Component based solutions such as state-machiny type things as React or more low level things as LitHtml/LitElement are great for just that: to create reusable components. But to wrap an entire Enterprise application, that contains all business logic and is constantly being improved on or added onto, in a hierarchy of components seems insane and leads to unmanageable code unless very strict guidelines and architecture is in place.

Components: great for (reusable) building blocks. MVVM: great to glue everything together on a more abstract and semantic level.

Unfortunately Knockout is losing ground fast in this regard, because people (myself included) do want to use modern techniques and components, and Knockout can't keep up with modern technologies, despite the excellent work of Michael.

@avickers We briefly talked about Web Components in another post. Since then I've adopted Web Components. Although you roll your own (if I recall correctly) and my goal is to be able to use publicly available 3rd party WCs.

The fact that styling is more efficient than just putting a bloated CSS framework in your head is an obvious source of developer pain

That's exactly why I want to use 3rd party components. I'm not a designer, and I don't like bloated CSS frameworks either.

I have been working on a set of tools to accomplish this. Right now, as a proof of concept I have:

• a patch for Knockout that fixes the template engine when used with WCs that manipulate the Light DOM. (Knockout in combination with 3rd party Web Components leads to messed up HTML #2500) as an alternative to Hardcoded references to templateSources.anonymousTemplate prevent a pluggable template mechanism #2523
• a custom properties-binding that does two-way binding with WC properties (there is https://github.com/FelschR/knockout-web-components but it doesn't do two-way)
• a custom options-binding that sits somewhere between the select binding and foreach and can work with arbitrary WC select lists

But I'm struggling on how to proceed from here.

We really need a Knockout-style MVVM binding framework that works nicely with WCs and other 'modern approaches' such as Electron apps (the CSP issue), etc.

I've thought about creating a set of bindings, but with #2500 and #2523 in place this will not work. I've thought about building on or forking Knockout or preferably TKO, but how mature is TKO? I've thought about abandoning Knockout all together and just create a simple binding library that does away with IE6-8 compatibility and just does what I need, but so much work has gone into the really robust binding mechanisms of Knockout that it would be a shame not to use it. Also to create something that mature by myself would not be realistic.

but if you guys are interested in more approaches and miss KO, I can see about actually typing up proper documentation and making the repo public.

I think we have different goals, but I really would love to see if there is common ground between our approaches. Don't bother with documentation though :-)

Anyway, sorry for the long read, but this is a really important topic as I think the Web Development community would benefit hugely from a shift back to separation of concerns, but right now we are losing the battle because the tools aren't keeping up with the times.

[aggrhm]

The strange thing is I too have created my own “framework” on top of Knockout that essentially allows for single file components like yours @avickers. It doesn’t yet leverage web components, but I think it should. It looks like @karimayachi has done the same.

It’s pretty obvious there is a strong demand beyond Knockout for a library that:

• uses observables and computeds to update the view of a universal custom-element component e.g. WebComponents (while still allowing me to use observables elsewhere, not built into the component)
• provides a DOM-manipulating view binding syntax to leverage those observables
• allows for single file components

I’m always googling for a library that does this, and am always amazed it doesn’t exist yet with the sheer amount of JS frameworks out there now.

Tying into some universal component support like WebComponents I think is paramount, so that projects can share components with others, whether they use observables or not. Take a look at Quasar for Vue, it removed so much wheel-reinventing in our code and saved us a ton of time.

Btw @avickers my note earlier about virtual DOM basically meant having some sort of DOM scoping, which a shadow DOM would provide.

[avickers]

Todo demo. There's a link to the repo with the code in the navbar.

I used Weightless components in a foreach, demonstrating compat with LitElement/Stencil libraries (re: #2500). I ended up wrapping them in my own component in order to control behaviors, but they worked directly, too.

There is a CSP, and it plays nice with Electron.

I made sure to put a binding outside of components in the index.html file, and created some single file components.

Despite being made from 3 "frameworks" (Knockdown, LitElement, and Weightless), it's still small and fast. This is why web components are great.

Although I didn't use it here, Knockdown has Buffer--a SSoT somewhat analogous to Vuex--to help keep your model in sync and separated from yours VMs.

Have we made the web great again or is there more missing?

[karimayachi]

@agquick

The strange thing is I too have created my own “framework” on top of Knockout that essentially allows for single file components like yours @avickers. It doesn’t yet leverage web components, but I think it should. It looks like @karimayachi has done the same.

We do have different approaches and requirements (I prefer SoC over -single file- components, as I can't seem to stop mentioning ;-) ), but I think what unifies our efforts is the need for a clean 'binding' library that plays nice with WCs and other 'modern' techniques.

Take a look at Quasar for Vue, it removed so much wheel-reinventing in our code and saved us a ton of time.

I had a quick look and I may be wrong as I didn't really dig into it, but it looks like a complete UI framework for Vue, much like Ionic Elements are a complete UI framework for Angular.

My library aims to be agnostic to what UI components are used. I have a early demo that uses Weighless, Wired Elements, Ionic Elements and Material Design Components Web Components without any UI-library specific configuration.

@avickers

Todo demo. There's a link to the repo with the code in the navbar

Thanks, looks promising. Very different approach to mine.

Have we made the web great again or is there more missing?

I honestly think this could make a difference. I believe there still is a place for agnostic two-way binding / viewmodels - libraries, now more than ever.

We have a couple of holidays here in the Netherlands the next few days, so I will try to make a demo like yours available.

Regards

[aggrhm]

I did some reading up on Web Components and I also think they are pretty promising. I put some time into trying to tie them to observables, but took a little different approach.

• For observable support, I instead used MobX (https://mobx.js.org/) which is a library specifically used for observables/computed/reactions/etc and framework-agnostic.
• I get somewhat annoyed with having the data-bind="..." for every dynamic binding, so I made my bindings work more like VueJS.

What I came up with was ElemX (https://github.com/agquick/elemx.js). An example JS fiddle for a Todo List can be found here: https://jsfiddle.net/agquick/z46vdtg9/

It is easily extendable using user-defined bindings, and comes with the most common ones already defined. I'd be really interested in what you guys think, so any feedback is welcome.

[karimayachi]

@agquick
Hi Allen,

First of all: sorry I didn't present the demo as promised. I actually did put it online: https://karimayachi.github.io/
It's probably buggy (and doesn't work on IE and Edge, which is more a problem of the WC UI libraries than of my code 😉 ), but it should give an idea of what I was trying to do. It's a custom KO-binding that does two-way-binding with WC properties. It only runs on my patched version of KO however. In the demo you can view the Todo- (actually Person-)list demo with 4 different WC UI libraries.

The reason I didn't present it here was that @avickers and I moved our discussion about 'The Future Of Knockout' away from this thread. We have been discussing this very thoroughly over the past month or so and we (sort of) concluded that a custom binding for KO wouldn't be the ideal basis for the goals we want to achieve.

I'm very interested in your approach. A quick look into MobX confirmed that most solutions (Andrew's and mine included) prefer using Proxies, etc over legacy browser compatibility.

I will check out your demo soon and get back to you!

[karimayachi]

@agquick
Hi again, I looked at your demo and source. Great work. You even have conditionals...

You and Andrew share the preference for single file components... Me, not so much. As for the Web Components: you bind to the attributes and (if I'm not mistaken) only one way. Since it's up to the developer of the WC whether or not to reflect the attributes to properties and since most developers focus on the properties, I really wanted (two-way) binding with properties. So that was what I did in my Proof of Concept. (And only that, for all the rest I used Knockout).

Edit: I think I was mistaken: you don't bind to attributes, but have a couple of standard bindings, such as text and click. I wanted to be able to bind to any arbitrary property the WC might expose. If there's a LocalWeather-component that exposes 'umbrellaIsOpened' than I may want to two-way-bind a boolean property on my ViewModel to it. I'm struggling a bit to see what problem you are solving. Knockout already does the text-binding stuff and wrappers for WCs already exist in (say) LitElement. Maybe you could elaborate on that a bit?

Anyway, very interesting approach. It resembles Andrew's take on things a lot.

Would you be interested in joining our conversation about this?

[aggrhm]

@karimayachi
Thanks for taking a look! Your proof of concept looks great too.

I'm pretty sure ElemX could be modified to separate out the html and css. I wish I could get you to come around on single-file components :). Creating 3 separate files for each component I need just creates so much friction for me for some reason.

That's a great point on the attribute bindings! It's an oversight on my part, I will definitely add. It was my intention that they be two-way bindings. Like you mentioned, several of the @ bindings are actually two-way already.

And sure I'd be interested in joining a conversation on this topic (shoot me an email at alang.graham at gmail dot com).

[karimayachi]

@agquick

I wish I could get you to come around on single-file components :)

Haha! Who knows.. It's not that I don't like single-file-components, it's that I don't like them for every situation.

And sure I'd be interested in joining a conversation on this topic (shoot me an email at alang.graham at gmail dot com).

Great, I'll email you tomorrow, now I'm running extremely late for an appointment😄