Knockout: 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: https://github.com/knockout/knockout/issues/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.

[agquick]

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..

[palsdm]

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.

[cosmoKenney]

+1 for sticking with knockout. I've been using if for something like 8 years. And in that time I've messed with Aurelia and Angular and glanced at React/Vue. All new development in our company continues to be in ko + punches + @knockout-contrib/router + typescript + typescript-ioc + webpack.

[Dmitri-Sintsov]

It would be nice to have short syntax:

<input :bind="{textInput: v, css: getStyle}">

or a bit more cleaner one:

<input :text-input="v" :css="getStyle">

[mbest]

@Dmitri-Sintsov Have you seen Knockout Punches? Using it, you can do this:

<input value="{{myTitle}}">

Or

<input textinput="{{myTitle}}">

[Dmitri-Sintsov]

It causes syntax conflict with server-side Jinja2 templates I use together with Knockout. So I am really happy that Knockout does not use double curly brackets, in contrary to Angular / Vue (although in Vue such "interpolation" can be disabled).

[Dmitri-Sintsov]

As Vue borrowed the basics from Knockout, perhaps Knockout could refine some concepts from Vue. Custom tags with slots are common nowadays, although Chrome has some native support for that, still there are enough of older browsers like IE around.

I like Knockout because it allows me to develop in pure ES5 no transpilers. To have the same experience with React, one has to install tops of Node.js stuff. With Knockout it's just a browser, even an old one.

Vue also allows to develop in ES5 quite well, however it has two major drawbacks for me - virtual DOM (custom event handlers can just dissappear sometimes) and that it enforces model view interaction with it's own Vue class instance, while in Knockout I can bind any Javascript class instance - I like later feature really a lot, I do not like when all of my classes are the instance of Vue with some mixins.

[cosmoKenney]

@Dmitri-Sintsov, @mbest,
I've been using KO for a very long time and I absolutely love punches!
Dimitri, have you checked out KO components for the custom tag support?

[Dmitri-Sintsov]

I do not develop SPA, I embed client-side Knockout.js code into server-side Jinja2 templates. Jinja2 already uses double curly brackets before Knockout.js has the chance to interpret them. Server-side executes before the client-side.

Knockout.js custom elements have no high level interface to define slots (insertion points for nested content):
https://knockoutjs.com/documentation/component-custom-elements.html

while Vue has it long time already:
https://vuejs.org/v2/guide/components-slots.html

But enforcing binding only to Vue instance instead of arbitrary Javascript object / class is a major flaw to me. Knockout.js architecture is more flexible and less obtrusive, but it could borrow some things like insertion slots from Vue.

[brianmhunt]

@Dmitri-Sintsov tko (albeit still in alpha) has support for slots/transclusion.

[agquick]

I agree Dmitri. I’m a huge fan of knockout but it’s becoming harder for me to propose it for new projects. I’ve looked at Vue but I also don’t like that all the binding has to be in a Vue component. My models themselves have observables and computeds which make bindings very easy.

The closest similarity would probably be React with mobx, but I’m not a huge fan of JSX. We currently use a custom component file like Vue that allows us to embed pug templates with the JS for KO components, works great. Support for slots would also be great though.

[Dmitri-Sintsov]

@brianmhunt Where is the documentation for slots in tko? I see you checked Vue.js features and port some of these to Knockout, that's wise and proper decision. I hope it still support pure ES5 browsers without the need to install large set of node.js tools. Also, why separate repositories?

[brianmhunt]

@Dmitri-Sintsov The documentation is the big missing piece for most of the @tko changes. Sorry it's not up yet; it's been on my TODO for a while and I just haven't had a chance to get to it. The best indicator of how slots work is the code comments related issue, and the tests. Documentation is (obviously) an area where tko could really do with some extra help.

TKO a separate repository because it's a complete refactor into modular ES6 components, so it can be compiled into the builds for consumption like it was with KO3.x, but also can be consumed as an import, for more granular choices on how it's used.

[ryios]

I still use knockout a lot, as it pairs well with legacy apps that use jquery and all kinds of bad JS all over the place that I can't really change.

I like that knockout uses the data-bind attribute for it's code as it keeps it away from the rest of the html and makes it easy for our designer to change html etc. It has a nice separation of concepts form backend/frontend/and graphics(styling, images, layout, etc).

Secondly I love knockout components and how easy it is to make bindings.

I've got a rather involved way of working with knockout though, I use Gulp JS and SASS and a slew of plugins.

My project structure looks like this:

gulp file attached
gulpfile.zip

I have a host header to the url in the gulp web server config in the gulp file. So I can type

"gulp webserver" and it launches my browser to my knockout app I am working on, locally and I get live reload support so I can just work on stuff in the editor, save, and see the change right away.

When I'm done, I have a single JS file for the app and a single js file for vendor stuff (local only) on our legacy apps the script tags are all over the place for the vendor stuff, I just leave that alone.

I use gulp-include to allow me to include JS files in other js files. That looks like this:

//=require _ko/bindings/*.js
//=require _ko/extensions/*.js
(function () {    
    var model = {}
    var module = {}
    model.module = module;
    //=require styles.js
    //=require html.js    
    //=require _lib/*.js    
    console.log(module.exports);
    var hash = new hashHelper();
    model.hash = hash;
    //=require api/api.js
    //=require objects/*.js
    //=require views/*.js
    //=require components/*.js
    model.api = successCenterApi;
    //helper function I wrote to call knockout register component in a way where I can pass it parameters to use in the constructor of vmComponentModel (like parent obejcts)
    registerComponent('my-component-here', getHtml('cmp/my_component_here.html'), vmComponentModel, model);       
    return model;
})();

So in this setup, I write view models for all my components (start with vm) and live in the components folder. I include them in main.js by using //=require components/*.js and so on for all my other javascript.

I also create models for templates I call "views" so if I'm building my component as a single page like concept, I'll have a template that always points to "currentView()" and that current view changes as you navigate the app and each view has it's opwn vObject (v for view) and all my views and component view models inherit base objects.

And I generally design my api.js so that I pass method calls observables so I don't have to literal my knockout code with .then promise calls etc. I can just do this:

api.Search(observableHere)

and if the api fails it sets an observable for the error that causes all the views to change and show the error page etc.

Knockout performs well in my scenarios and I see no reason why I shouldn't use it, it's stable and feature packed and is really flexible.

Worth noting: with this project structure and gulp-html-to-js my html compiles to inline js to a .stage folder, and then I use gulp-include to include said html into my app. So I can work on my html in individual files.

I use templates to bind the html with the html binding so I have templates with said html I can use everywhere I want them.

<script type="text/html" id="templateView_Content" data-bind="html: base.module.exports['html/templates/content.html']">
</script>

I like this setup because there's only one js file to load, there's no url requests happening not associated with api rest calls after that. Even the images are in the JS file. So once users have the app.js file cached their page loads are super quick.

[bludev]

I think that many developers are reluctant to use KO because they think (wrongly) that it is an instrument that is little used, outdated or poorly documented. To make a comparison, since the beginning of the year in StackOverflow for the [knockout.js] tag there are 70 threads, while [angularjs] has 1480 and [vue.js] has 2433. Like when you want to choose a place to drink a beer, most people enter the busiest one!
Of course, ko 3.4.2 is stable and complete, but I think it is necessary to increase the visibility and dynamism around this wonderful tool, otherwise we will gradually lose the most important and necessary factor for the survival of KO: the community.
In my free time I would like to be able to actively contribute to the development of KO, but I honestly do not know where to start! I have created and updated the Italian page in Wikipedia, I invite other users to do the same in their languages ​​of competence.
I find interventions such as @ryios very useful, but it would be more useful to bring these examples into a dedicated section of the ko website. What do you think?

[cosmoKenney]

@bludev you are right that angular and react and vue seem to have lots of followers. I still cannot figure out why. Angular is a huge framework and I personally don't like it. Nor do I want to do things their way. And when it comes to jsx -- no thanks. I want my view-model separate from my view templates.

As for documentation of knockout, I love the knockout site documentation. Every thing you need to know is right there and I can always figure out how to solve a problem. Whereas take a look at Aurelia, for instance. I could never figure out how to navigate the docs to get productive. And with angular, it seems that once you get past the tutorials, you are pretty much on your own. Though, I haven't looked at it in a while.

And unfortunately TKO is going to fail due to horrible docs. And, here again, like Rob Eisenberg of the Aurelia project, we are faced with a developer with good intentions. But, Brian Hunt has has baked a lot of _opinion_ into the TKO framework. Not sure it's something I would try to use on the next project I start since I have a good working skeleton with plain old Knockout, Punches and the KO Component Router with typescript, webpack and typescript dependency injection, served by dotnet core.

[chrisknoll]

Nor do I want to do things their way. And when it comes to jsx -- no thanks. I want my view-model separate from my view templates.

Ha ha, I think we were separated at birth, you have the exact same perspective as me.

And unfortunately TKO is going to fail due to horrible docs. And, here again, like Rob Eisenberg of the Aurelia project, we are faced with a developer with good intentions. But, Brian Hunt has has baked a lot of _opinion_ into the TKO framework.

I _think_ I understand that the way TKO was structured, it does incorporate a lot of the ideas that B. Hunt wanted to see in how the library was structured. But as a consumer of the library, I'll have no problems using TKO (knockout v4) if it passes all the current testing specs and allows the same level of flexibility (custom data bindings, observable extenders, etc). To me, it's just adding a dependency in my project and calling ko.applyBindings()....any deep opinions put into the core implementation is hopefully hidden from me...

The only risk, tho, is that if that influence 'is a turn off' for other collaborators to contribute improvements, that would be a negative impact, but from a 'library consumer' perspective, I not going to care too much about the underlying design (provided the underlyign design doesn't turn it into a 500MB library, of course!)

[Dmitri-Sintsov]

Still it would be nice if the repositories of Knockout and TKO would be merged into one repository, or at least the major features of TKO (slots for components) would be backported to "main" Knockout repository. Fragmenting code base does not increase the library popularity and potentially makes the code more bugs prone - less code reviews, less tests, separate users.

It's funny (and cool) that even today Knockout's implementation of TodoMVC is one of the smallest around. And it works fine without any of node.js tooling, just plain ES5 in browser. While that is possible with React, it is magnitudes harder to work with React in plain ES5 without the node.js tools.

[cosmoKenney]

Another thing I always hear about about KO is the perception of slow rendering. I don't know where that comes from. I just pushed a new KO SPA project to prod and everyone who uses it says it's ridiculously fast. It seems that if you build the entire project with KO components and manage your bundles correctly, the binding and rendering is blazing fast.

[chrisknoll]

There's a cross framework benchmark that shows KO is slow at rendering a 10,000 row table and appending 1,000 rows to a 10,000 row table. Personally, I page my datasets such that I never render 10,000 rows of anything but it's certainly something that people point at, so getting an optimization to dom updates in foreach bindings is something that is being looked into.

But, that being said, I also feel my KO ui apps are pretty responsive and snappy, even with complex object dependency observers.

[cosmoKenney]

@chrisknoll yes, I have an old legacy app with 50 entry pages (think webpack entry element with 50 entries in it), it has lots of pages with lots dom manipulation with multiple foreach bindings. Those pages have a noticeable delay when rendering. But for some reason rendering in my newer apps with pre-registered components in a foreach is way faster. [at least that's my impression].

[brianmhunt]

Just as a matter of interest, on the topic of TKO's opinions, the intention (whether I succeeded or not) was to have an opinion about a "knockout" build, a "tko" (kitchen-sink) build, and leave it to users to piece together the modules on a mix-and-match basis that suits them best. For some, content security policies are important, others JSX, others simple and minimalistic. The optimal TKO opinion in my mind is that it should be easy to demonstrate capabilities of TKO (low barrier to entry), but let users make up their own mind on how it should be built once they're familiar (high customizability). The challenge right now is that it's a big old box of undocumented code. The docs are next on my TODO (aside from any key forward-ports).

On the 10,000 row test, the last time I tested TKO the JSX build came in near Inferno, around 10x faster than KO with vanilla data-bind and near the top of the performance-heap. Conceptually, KO is going to be faster than virtual-dom for complex DOM states, particularly where there are a lot of small changes at the leaves. The more complex the app, the bigger the performance benefit of an observable-DOM model like TKO. It's also going to be pretty snappy for light workloads. From a performance perspective the virtual-dom does well is in the middle-ground, with apps of moderate DOM-depth complexity. There are, of course, lots of other reasons to use virtual-dom frameworks.

On the merging of the repositories, the intention of TKO would be to eventually subsume the KO repository (notwithstanding keeping the KO repository around for maintenance of the 3.x line), since KO would just be one variant of KO based on the modules chosen.

Thanks for all the feedback. 🍻

(Aside, if you'll please pardon the shameless plug, contributing to my Patreon does allow me to carve out more time for TKO)

[cosmoKenney]

Thanks @brianmhunt for taking the time to comment here. I'll come back around and try TKO on my next project.

[ryios]

Yeah in my experience KO is pretty fast. Especially when you load all your html into inline js and do templates like this:

<script type="text/html" id="xyzenterPartial_Header" data-bind="html: base.module.exports['html/templates/partial/header.html']"> </script>

I kick off my knockout projects from a single knockout component and on the html for that component I load all my templates to script tags like above.

Then I can just data-bind="template:... " all of my templates and pass data scopes to them.

Additionally, for big data sets involving public data, we use Google's Compute platform and we build indexes with them with google cursors. So I'll fetch 100 items, and either write scroll/load logic on the cursor, or have paging, or a load more button.

Basically, my KO apps load from a single js file, everything is in there, even images, and it's really fast.

I'm attempting to come up with a way to design everything as components with sub components, but haven't tinkered with that concept yet.

But you can override component registration in a way where you can pass additional data to your component view models allowing you to pass data from a parent component to a sub component when you declare it via it's params attribute.

[ryios]

What I really wish knockout had, is a way for me to register components as sub components of other components. That way a sub component can only be declared inside it's parent element. I'll do some digging on that eventually and might end up writing my own component binding or maybe something called 'registerChildComponent(parentComponentTag, args)'

Eventually I want to create an entire set of components for bootstrap3/4 in a way where I can do stuff like this:

<ui-row params="css: 'main-row'">
   <ui-col width="3" offset="2">
       <ui-form action="/something">
           <ui-datePicker
       </ui>
   </ui-col>
</ui-row>

Where ui-row is a div with a class of row where you can do params for any ko binding. And the sub components automatically pick up the $parent and $parents contexts etc.

Slowly, build an entire UI system like this, so that the entire app is built on it. Then if we change to bootstrap 4, we just update the Style Guide components, no html to change in the app.

But dunno, just a theory.

[nkosi23]

I think it is better to let the client handle depency injection / ioc outside of knockout. Things such as requirejs should allow you to achieve what you are after by building on top of knockout component system.

Such features would introduce strong opinions on the way ko should be consumed and the project would end being a poor man's version of angular. Especially since this type of use case is quite marginal.

As far as we are concerned, we aren't at all into the dependency injection / requirejs etc... train, and I'm sure we're not the only ones especially among those using ko.

Make no mistake, we use these design patterns a lot server-side with the strongly typed stacks that we use. However we are of the view that javascript is a scripting language, and that this calls for developers making strong assumptions on the environment in which the code will run. Especially if you factor in the fact that Javascript is a dynamic. But this is a feature of scripting not a bug, because assumptions enable code simplicity.

Typescript strikes the correct balance and we use it heavily. But we have no plan to embrace inversion of control client-side. It is like deciding that shell scripts should be written using strongly typed design patterns. You lose more than you win, and in particular you lose on a lot of flexibility and simplicity (and the flexibility of scripting does not have to mean maintenance nightmare if you know what you are doing).

Just to say that hopefully, ko will not start making this type of decisions for users, and will not force us to go through hoops to use ko as a script.

[cosmoKenney]

@nkosi23 i agree wholeheartedly that ko should remain as close to how it is today as possible. In that please don't bake IOC or other giant features into the library. Keep it simple. Obviously TKO is a necessary step for the evolution of the library. But keep it a simple library so I can pick and choose all the other pieces myself. I.e. I use the great typescript-ioc library to add dependency injection through decorators. I'm familiar with it but I would hate for TKO or KO to force something like that on us.
And if we ever get to the point of building a CLI (I may try to work on this myself) for KO/TKO, let's make it pluggable so I can use ES6 or TypeScript or Babel or whatever. Let me pick my IOC. Let me pick my bundler. I love webpack and would hate to have to use anything else. Anyway you guys get what I'm getting at. K.I.S.S.

[BMeyerKC]

It takes all of us to keep Knockout alive. When I chat with other developers, I ask about front end and then I mention Knockout.

Those others spend marketing dollars, which I can't figure out why or how that is profitable.

We need to keep Knockout in the main stream, continue talking about it. Show it off in mock ups, let the people discover how awesome it is!

[palsdm]

Very true. :)

On Fri, Mar 1, 2019 at 3:24 PM Brandon Meyer [e-mail]
wrote:

It takes all of us to keep Knockout alive. When I chat with other
developers, I ask about front end and then I mention Knockout.

Those others spend marketing dollars, which I can't figure out why or how
that is profitable.

We need to keep Knockout in the main stream, continue talking about it.
Show it off in mock ups, let the people discover how awesome it is!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/knockout/knockout/issues/2106#issuecomment-468701455,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aj2AjBn90YGbaVYGM-no5m6_x_CBpXMoks5vSUY1gaJpZM4JWHvK
.

[QDCSLG]

Yes, it is true. We need to keep knockout alive.

In my company, we have few groups using different technologies. Some use
React, some use Angular. My group uses knockout. The productivity is
totally different. The learning curve to knockout is so much better.

Anytime anybody want to argue with me about the benefit of other
frameworks, I will just point to the significant difference in
productivity. My group delivered multiple complicated projects while they
are still struggling some basic react/angular setup. Their customers are
not happy about those guys productivity.

On Fri, Mar 1, 2019 at 9:24 AM Brandon Meyer [e-mail]
wrote:

It takes all of us to keep Knockout alive. When I chat with other
developers, I ask about front end and then I mention Knockout.

Those others spend marketing dollars, which I can't figure out why or how
that is profitable.

We need to keep Knockout in the main stream, continue talking about it.
Show it off in mock ups, let the people discover how awesome it is!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/knockout/knockout/issues/2106#issuecomment-468701455,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AL-27sAQ6L5-r2cePsZa4f9eAtZnFeKPks5vSUYxgaJpZM4JWHvK
.

[agquick]

I think we all see the value in Knockout so we should pivot this conversation into strategies to keep Knockout relevant. I've used React, Angular, and Vue and for some reason keep coming back to Knockout, for the same reason you mentioned: productivity.

I'm not in favor of turning Knockout into "framework" but I think there are a few things that will modernize the library. For example in our company, one thing we've done is added support for single file components in Knockout. In one file, I can define a "View" (view model), the corresponding view template, and relevant css, and the entire thing becomes a knockout component. We've defined a View and Model class to provide helpers around common things that apps usually need (e.g. model fields become observables automatically), but you can still use vanilla view model bindings without a problem and sites can work fine without using those classes (so it still has the "no forced framework" feel).

Anyway, for me at least the future of Knockout involves some solution where single-file-components are a primary feature, like Vue, React, Riot.js, etc.

[nkosi23]

What you describe is turning knockout into an opinionated framework like Backbone.js. I think the value of knockout is that it is a library that you can use to build frameworks such as the one you describe on top of it.

From what I understand, one the goals of tko is to make it easier to find plugins, for example providing behaviors such as the one you describe.

We use a proprietary framework based on ko doing exactly what you describe. We plan to migrate to an in-house developed lightweight framework still ko-based. The fact that ko is not a framework but a library is very useful for this flexibility. and I think this library-nature is even central to its DNA. But I think you're right to point that there is value in improving the discoverability of third party plugins. Maybe a community website listing such plugins is what we really need. Could be as simple as something hosted on github.

This makes me think about something. Maybe ko should be presented differently. My feeling - I don't know if I'm right but - my feeling is that people using knockout seem to have quite a bit of technical maturity and tend to do relatively non-default things compared to other communities. Just in this thread we've seen plenty of people describing relatively extensive frameworks built on top of knockout.

I would contrast this with angular, react etc... where the majority of people stick to the out-of-box features and would wait for months for a feature to be shipped as a default convention rather than extend the library. By contrast, people choosing knockout seem to be comfortable having more control on the architecture and conventions of their systems.

So I'm thinking that maybe, what ko needs is to change the way it presents itself and from now on could present itself as "a framework for building UI frameworks exactly matching the needs of your application."

"No need to overcomplicate or oversimplify, Ko's powerful engine makes building extensible frameworks exactly matching the needs of every application extremely easy. Ko has you covered: whether your application needs 3 lines of code to display a simple view model or 1 million lines of code to manage a complex Single Page Application, Using ko allows you to build extensible, and maintanable applications having any complexity, from the very simple to the very complex. You can use ko straight away and have a production-ready application in a few lines of code without any ceremony being required. Ko empowers you to develop your applications using any style, convention and architecture you want."

"Ko also empowers you to choose among a rich ecosystem of plugins to add exactly the capabilities your application needs in no time. from routing, all the way to single page application tools and conventions, the community has developed tools and architectural styles accomodating many needs using the power of knockout. But many people choose knockout for the ease with which they can write the exact features their system needs whenever they need them. For ko empowers you without restricting or limiting you."

"Ko is the simplest way to build powerful applications of any complexity with minimal friction and ceremony. with ko, you are free to make your application as simple or as complex than it needs to be. You have total control over your project."

And once this marketing job is done, the copy can continue with the usual presentation of the features of ko-core.

I think that this would allow people to value ko for what it is and avoid comparisons with opinionated frameworks like angular and react. Right now, people are comparing Apples to Oranges when it comes to ko, because the term "UI framework" or " UI library" is associated with a broad set of expectations nowadays. So my thinking is that, instead of trying to match every expectation, the real need may be to adjust the message and optimize the way we explain to others what makes ko unique. Then the awesomeness of tko will drive the last miles to firmly root the long-term relevance and success of ko.

FoundationDB has a similar branding message: it is a database framework for building a database. I think ko has always been a framework for building your own framework on top of it (even a very lightweight framework is a framework. for even not having a framework is already a framework since it is a design/structural decision), but there weren't really a need to present things that way until now.

[caseyWebb]

We use a proprietary framework based on ko doing exactly what you describe. We plan to migrate to an in-house developed lightweight framework still ko-based. The fact that ko is not a framework but a library is very useful for this flexibility. and I think this library-nature is even central to its DNA. But I think you're right to point that there is value in improving the discoverability of third party plugins. Maybe a community website listing such plugins is what we really need. Could be as simple as something hosted on github.

This is my intent with https://github.com/Profiscience/knockout-contrib, although it can still admittedly use refinement. Certain parts are very opinionated, but every package is opt-in and are designed to be flexible enough to work with custom implementations. @brianmhunt has also expressed interest in the past about incorporating some of these packages into TKO (I'm personally hesitant to until/unless TKO moves to TypeScript, but that is something that should also be open to discussion. Personally I will never use vanilla JS again.)

I'd really like to have a Knockout or Knockout-Contrib org on GitHub/NPM. In fact, I was originally going to publish on NPM as @knockout-contrib/meta and @knockout-contrib/<package>, but also didn't want to step on toes or hog a namespace.

[QDCSLG]

I am not sure if I am the only here who don't like the one file component
solution.

In my project, I keep HTML and JS seperated as much as possible. My team
members all like this separation between html and js.

I don't think the single-file-components should be in the core knockout.
You can certainly create plugin to implement this.

This is the beauty of knockout. It is a library. It is not opinionated.

On Fri, Mar 1, 2019 at 3:16 PM Alan Graham [e-mail] wrote:

I think we all see the value in Knockout so we should pivot this
conversation into strategies to keep Knockout relevant. I've used React,
Angular, and Vue and for some reason keep coming back to Knockout, for the
same reason you mentioned: productivity.

I'm not in favor of turning Knockout into "framework" but I think there
are a few things that will modernize the library. For example in our
company, one thing we've done is added support for single file components
in Knockout. In one file, I can define a "View" (view model), the
corresponding view template, and relevant css, and the entire thing becomes
a knockout component. We've defined a View and Model class to provide
helpers around common things that apps usually need (e.g. model fields
become observables automatically), but you can still use vanilla view model
bindings without a problem and sites can work fine without using those
classes (so it still has the "no forced framework" feel).

Anyway, for me at least the future of Knockout involves some solution
where single-file-components are a primary feature, like Vue, React,
Riot.js, etc.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/knockout/knockout/issues/2106#issuecomment-468814261,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AL-27tYlfd9ZIcM-bPuB5iRbsH4T1cEgks5vSZibgaJpZM4JWHvK
.

[caseyWebb]

I'm also not in favor of introducing required build dependencies; implementing things like single file components could easily be accomplished with a separate package. IMO even JSX/TSX is a stretch, and the only thing that would actually make it worth it for me is if there was actual type-safety in TSX re: bindings.

[cosmoKenney]

@QDCSLG, @agquick Like @caseyWebb, I personally do not like the JSX style of component declaration in in a single file. Remember when separation of concerns was a big deal? I feel like KO's MVVM paradigm was a great design choice. It lets me keep html in an html file and view-models (and logic) in a TS or JS file.
But I can see where something like a webpack loader that took a JSX file and produced the necessary run-time component bits (like a pre-processor) would be cool if it didn't require changes to the KO library.

@all, if you haven't tried @caseyWebb's router and other ko related stuff, its excellent. I have a website in production now that is using it, and I can't imagine building my next ko based website without it.

[agquick]

I see your point @nkosi23 and I'm in favor of keeping it light. Maybe you're right and Knockout just needs to focus on providing visibility into the plugins that exist to build your own framework (I'm guessing that's part of the goal of TKO maybe). For example, every project we use mbest Knockout Punches.

But my point still stands: you can't really just pick up and run with vanilla Knockout, and I think that's why we ALL have such push back recommending it for new projects. You have to take the time to build your own framework on top of it which novice devs can't do.

I really see components (no matter what framework) as the future of Javascript front-end dev, and FWIW adding the single-file-component support in our build tools heavily increased the use of KO components in our code amongst our developers. I'm honestly surprised that some people in this thread still prefer to create 3 separate files for JS, css, and templates for every single component! There's no way my devs would switch back to that if I asked them too. I do however agree with @caseyWebb that it should be a package separate from Knockout.

I literally almost switched to https://riot.js.org/ just from the simplicity of first code example on the home page, if we could have something similar for Knockout I really think it would revitalize the library in 2019.

[nkosi23]

I am not sure if I am the only here who don't like the one file component solution. In my project, I keep HTML and JS seperated as much as possible.

Same here, I read @agquick too fast (however the remarks about the fact that this behavior can be best implemented as a plugin still stands).

Actually we do not do "single file", what we have are pretty much conventions to load the right viewmodel based on the view (but even this shows its limits and is causing too much rigidity). We keep HTML, JS and CSS separate, I 100% agree with those saying that separation of concerns is important.

@cosmoKenney @caseyWebb, sounds cool I was lately looking for a cool router having optional view caching on a per view/route basis. But if the router is a tiny core allowing us to easily extend it, will also help. I'll definitely take a look, thanks for bringing it up.

[flavioalvesdias]

Still it would be nice if the repositories of Knockout and TKO would be merged into one repository, or at least the major features of TKO (slots for components) would be backported to "main" Knockout repository. Fragmenting code base does not increase the library popularity and potentially makes the code more bugs prone - less code reviews, less tests, separate users.

Many say that knockout does not support Slot, and is true, it does not, but since version 3.0.0 released in 2015 you can do the same thing using $componentTemplateNodes. It is very simple to use and you have a similar result.
sample.txt

[avickers]

I don't think the ills of the Knockout ecosystem have much to do with missing features from the core library.

Knockout used to be the quickest and easiest way to get started. Now, it's quite possibly the slowest and hardest.

Knockout hasn't changed very much. So what has changed?

If you want to begin growing the Knockout community again, then Bob's your uncle.

[agquick]

Exactly, I think that's my point too. I'm all for keeping Knockout simple and preventing opinionated decisions etc, but these other libraries have evolved to a point where you can get started pretty fast (without trying to roll your own framework on top of it). I'm just trying to help prevent Knockout from becoming obsolete because I'm so much more productive when using it, and observables/computeds + components just makes sense.

I know I've gotten a lot of pushback from ppl regarding single page components, but that is almost the entire appeal of all these new popular frameworks (React, Vue, Riot, Marko, Mithril, Polymer ...) It seems almost negligent to ignore that.

Again, I'm not saying it has to be rolled into core knockout, I'm just saying on this current path we're all going to be saying "Remember Knockout?" in 5 yrs.

[Dmitri-Sintsov]

Which framework / library offers more features, has clean syntax of templates when coding for IE, no ES6, no node.js transpilers? React is quite horrible when coding in pure ES5, comparing to Knockout. Vue is ok for ES5, but it has very strange architecture, where all of the observable objects has to be the instances of Vue class. I'd like to bind to my class with the name that reflects the type of object, which is possible in Knockout. I consider trying Marko.js but it still has no two-way binding. And Stencil.js has only components but no for-loop support, afaik. I saw TodoMVC for Stencil, they used raw templates in for loop.

Knockout probably would have chance to surivive because it's base ideas are clean and well-working ones. But fragmentation of repositories makes less change for that. Insertion slots is obvious missing feature in this repo. Split hacks is not the optimal way for slots.

[nkosi23]

I know I've gotten a lot of pushback from ppl regarding single page components, but that is almost the entire appeal of all these new popular frameworks (React, Vue, Riot, Marko, Mithril, Polymer ...) It seems almost negligent to ignore that.

It's a little known fact but the last thing you want to do when you compete with someone, especially someone more funded than you (either literally - like Facebook behind react - or in terms of assets - such as code contributor), the last thing you want to do is to compete on feature parity.

Even when you are indeed a direct competitor, the smart approach is to reposition yourself and convince the market that you are "really in a different business'" calling for a whole different value scale. So when you're not even really a competitor as is the case for ko, trying to imitate popular frameworks is in my opinion not a wise course of action.

Even if this was to be successfully executed, this path will only turn ko into one more player in a hyper-crowded space. For there is no reason people will magically switch to ko after you introduce these frameworks. However, once you do that, you've officially become a wannabe, another horse in this race.

Marketing strategies must be 1) grounded on your brand equity 2) aligned with your DNA and 3) based on what you can realistically have in the worst case scenario, not based on what you wish you'll have. Otherwise you go broke when things go jazz. With open-source this means lacking contributors, bug fixers etc... because of your huge API and the complexity due to your ambitions that has been made impossible to sustain because of your lack of traction.

One thing not to forgot is that when we to talk about ko's future, let us also remember why ko is still alive: because even as little as 1 to 3 individuals are able to maintain the project and keep it bug free. We must be careful with Venture-capital-like mindsets (burning more than you earn, taking loans over future earnings etc...).

But once this is said, I do not want to make it sound mike my point is: "let's go the framework for creating a framework way because of limited means, but in ideal world we would have imitated react". My point is that when you are naturally differentiated like ko, joining a crowded race isn't a smart course of action because like many others I strongly believe in ko's value proposition.

When you are smaller than your competitors, go premium. This is not even about luxury, this is about staying in business. When you are small, focus on people who can afford your service at the price point you need (in our case, wealth is the technical maturity / slight independence of mind required to get started with ko). This doesn't mean snobbing the rest, you want to convince and provide tutorials etc... but you need to know who your customers are.

Then as the top payers come (here, the people with technical maturity building frameworks on top of frameworks), the crowd will follow. They will initially come as users of the 2nd degreee frameworks. This will be indirect and slow but in the meantime you keep a profitable and sustainable project.

For when you do not have a large following, you need to have the best solution to the problem you are addressing. You want to have the truth and stick to it. Because, inevitably, people will be tired of switching frameworks every 4 months and at some point they will wonder "what is the truth?", they will say "there has to be a better way". And you want to be there when they come to that point. You want to have the right message and the right positioning, the right polishness and the right technical maturity. But if you are out of town because you decided to follow the hype, you will lose on every count.

The business of the truth is a cyclic business. Initially people hear the truth and are excited about this new liberating message and you have a huge boost. These are your initial haydays. Then people notice your paradigm, and decide that they want to make a buck too. So they add to it, they turn your general wisdom into straightforward lifestyle instructions, and they write book after book, lifestyle rule after lifestyle rule. Do this, do not do that each one giving incompatible advice. For because life is confusing, everybody is insecure and craving for answers to their questions. everybody wants a guru, except for the few people who have found freedom.

So you have a market crowded with gurus, but each of them has deep limitations and inconsistencies, because you can't simplify wisdom without facing consequences. For wisdom can't be purchased or cloned on GitHub, there is no way around it. For finding wisdom is the duty of every man during their life, both rich and poor. They will have to (1) seek it, and (2) medidate on it to find it, there is no shortcut.

But eventually, everybody will converge toward it. Some at the end of their life in their 60s, some at the beginning of their life because they can feel that something is wrong with the way the majority lives, so they look for answers.

So there are 3 takeways from this. The first one is that wisdom is a vocation more than a business. You can't run a sustainable business by selling wisdom only, because you'll run out of money long before you have enough customers. So you have to find a way to minimize your operating expenses to the greatest extent possible so that you can focus on money-making activities at the same time.

This is best achieved by focusing on wisdom, that tends to be very compact by nature (ie, ko-core). Then, an opinionated plugin-ecosystem is how you bridge the gap with the market. But this approach allows you to do so without compromising on your wisdom. With this understanding, the plugin ecosystem is less about running after the market, than it is about strategically funneling the market to your wisdom.

I think that at the minute, ko was missing this bigger picture that I have just painted so it started to doubt ko-core. But I am convinced that all ko-core needs is a message optimization, not a repositioning. Then tko will provide the sound foundation required for a dynamic and consistent plugin ecosystem, and once we have that we are set for the future.

What will be needed is an appealing plugin discovery platform, strategically branded, positioned and conceptualized, to further the strategic interests of the project in light of the picture painted and the current shape of the market.

I have some immature ideas about it, so I will continue to think about it over the next couple of weeks to let that mature and I'll send a proposal (by mid-April).

[QDCSLG]

I see your point @nkosi23 and I'm in favor of keeping it light. Maybe you're right and Knockout just needs to focus on providing visibility into the plugins that exist to build your own framework (I'm guessing that's part of the goal of TKO maybe). For example, every project we use mbest Knockout Punches.

But my point still stands: you can't really just pick up and run with vanilla Knockout, and I think that's why we ALL have such push back recommending it for new projects. You have to take the time to build your own framework on top of it which novice devs can't do.

I really see components (no matter what framework) as the future of Javascript front-end dev, and FWIW adding the single-file-component support in our build tools heavily increased the use of KO components in our code amongst our developers. I'm honestly surprised that some people in this thread still prefer to create 3 separate files for JS, css, and templates for every single component! There's no way my devs would switch back to that if I asked them too. I do however agree with @caseyWebb that it should be a package separate from Knockout.

I literally almost switched to https://riot.js.org/ just from the simplicity of first code example on the home page, if we could have something similar for Knockout I really think it would revitalize the library in 2019.

As to the single-file-component, I remember knockout will first clone the html into the DOM then bind the HTML with the context. In this case, if you have css content in the component, it will be duplicated multiple time. The HTML elements needs to be duplicated multiple time, but not the css element.

I think it is better to have css seperated from the html and js file and use other way to load css on demand.

[ryios]

I don't have three separate files for every component, I don't even use AMD or require.js.

I have html files, scss files, and separate js files, and I run gulp-compile and I get one Js file that has the whole app in it. Minimized at about 27kb.

Here's the page source example:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="google" content="notranslate">
<title></title>
<link rel="shortcut icon" href="#" />
<script src="./vendor/vendor.js"></script>
<link type="text/css" href="./vendor/vendor.css" rel="stylesheet" />
</head>
<body id="myApp">
<div class="container">
<my-app-here params=""></my-app-here>
</div>
<script src="./myAppHere.min.js"></script>
<script>
$(function () {
ko.applyBindings(document.getElementById("myApp"));
});
</script>
<script type="text/javascript">var _lrscript = document.createElement('script');_lrscript.type = 'text/javascript';_lrscript.defer = _lrscript.async = true;_lrscript.src = '//' + ((null||location.host).split(':')[0]) + ':35729/livereload.js?';document.body.appendChild(_lrscript);</script>
</body>
</html>

That's all you see when you view page source.

I can work on all my component html, js files, scss files, etc all separated by a folder structure and it just auto refreshes into a single file, live reload, etc etc.

Now I don't have source maps, so when I'm debugging in the browser I have to know where that code is, but that's not too difficult because everything is broken up into object classes/functions and I know which object is which file (names match).

The app.js file has all the styles in it at the top via css converted to js, the css has all the images in it compiled to data-url base 64 encoded formats.

My overall goal here was to limit web requests for static assets to as close to 0 as possible, in this case we have 4 (index.html, app.js, vendor.js, vendor.css).

I was playing with the idea of embeding the js directly into index.html, but realized that it would never cache due to default documents in web servers, the root path never caches in some contexts.

[caseyWebb]

The app.js file has all the styles in it at the top via css converted to js, the css has all the images in it compiled to data-url base 64 encoded formats.

I don't believe this is ideal with HTTP/2, as you're losing all concurrency and incurring a runtime hit parsing and inserting the CSS and images (probably negligible, but as this seems a microoptimized setup, worth mentioning). I personally inline my CSS (via webpack), but not images, and it's all chunked and loaded on-demand.

[agquick]

I don't put the css in the html template, I have a custom file extension that I use for single file components similar to Vue.js. My file looks similar to:

class MyView extends QS.View {
  init(opts) {
    this.title = ko.observable("my title")
    /* setup observables and computeds */
    ...
  }
}
MyView.registerComponent("my-view")

<template name="my-view" lang="haml">
.my-view
  %p Here is my view with title: {{ title }}
</template>

<style lang="sass">
.my-view
  p
    color: #0000ff;
</style>

QS is my "pseudo-framework" called QuickScript built on top of Knockout, but it really just provides helper functions, most of the look and feel is still plain Knockout and Knockout Punches. This is obviously a rough example to give you an idea. The template tag gets transformed to a JST template which I've modified Knockout to know how to use, and the style tags get added as an inline style on the head tag only once when the component is registered.

It all compiles down to a single JS file. But this approach is what I meant by avoiding creating separate html, css, and js files. Our developers seem to like it and it encourages strong usage of components (we noticed the need to always create separate files made some people lazy).

[ryios]

Our app does load content from a cms that can contain image links, videos, and so on.

The way it works is similar to this concept:

A CMS provides content to google app engine via a rest api.

A python app builds an index and crawls said CMS rest api and indexes content and removes old content (no longer in rest api).

The app, built as a single JS file interacts with a google search api on the google cloud to navigate our content. Utilizing the power of google search faceting etc etc. The app has an api layer where it makes calls to the google api and our live api for the parts we need to be real time (not based on search index). The index contains HTML content.

So it's kind of like a headless cms concept where we build a custom front end.

It has images compiled into it by design, the goal was to have a single JS file we could put anywhere to create instances of the application in multiple locations without doing anything fancy, just drop the script on the page and put the component in the markup where you want it.

All we have to do to update it is run gulp-compile and throw the new script version up on the cms.

I wouldn't normally compile images inline in the css and compile the css into the js, but we wanted to avoid "Link to this css, images, etc" we wanted it to all be in the js file.

For some things, like css deviders, custom icons etc, I think inlining the images in the css makes sense. Actual content images, yeah, they're linked with img elements.

I think this just adds to the complexity of the 1000 ways you can use knockout. I love knockout, don't get me wrong, but there's no rigid conforms to use it, but that's why it's awesome. But I also think that's why it's not more popular.

[ryios]

What I think would be cool, is to create a vsCode extension that supports nested files on a file item, kind of like how Visual Studio separates ASPX and ASPX.cs on a single item. You create a new aspx page and you get the markup and the code in one file item.

Imagine if you could create a new "knockout component" file type in VS Code and you called it "shoppingCart" and it's exandable.

Under shoppingCart you got "shoppingCart.html, shoppingCart.js" for free. And shoppingCart.html and shoppingCart.js were already wired up for you with a pseudo name following some kind of component js pattern.

In this way, you get the best of both worlds. You can create 1 item 1 time, and get 2 separate files that stay in sync with each other.

In a perfect world, I'd want to change an observable on my view model in shoppingCart.js, and have the markup automatically refactor that name if I was using that observable and renamed it.

Not even MVC Razor templates in .net core MVC in Visual Studio do this though, it's a pipe dream.

This would follow a folder structure like this:

• Components
• 
  
  • shoppingCart
  
  
• * * shoppngCart.html
• * * shoppingCart.js

Using webpack or gulp-include I could probably come up with a build that automatically puts the shoppingCart.js in the shoppingCart.html for you.

In this way, you don't have 300 lines of JS in with your 100 lines of html, very hard to navigate.

A lot of modern editors can actually let you navigate JS file functions and classes now if you write them right.

I.e. in VIsual Studio I can actually add code regions, and delcare function bodies, and they show up in the function navigator.

This drop down even tells me which functions are private and which ones are public (exposed on this).

And it works because it's a flat JS file, it only acquires it's namespace containers during build.

Now I could be behind the times, cooler editors, etc, who knows.. But I'm always looking to learn better ways to do stuff and better tools.

[cosmoKenney]

@ryios I think there are extensions that already do this in VS Code. And I know for certain it's doable in Visual Studio 2017/2019. Here's a screen shot of VS2019 nesting ".ts" under ".html" on my computer (very easy to setup):

Also, add a knockout component project item template to the "Add" box (not as easy as file nesting but I got it to work with some trial and error):

So all I do is right click the folder where I want to add the component, then Add -> New Item -> Knockout -> Knockout Component. Then I type in the name of the component and get a basic html file and ts file with a class name that matches the item name I typed in. Plus code for registering the component.

BTW I was hot for VS Code for a while (before we moved to VS2017). But since my company provides us with a Visual Studio Subscription, I have started using VS2017 for all project and am migrating to VS2019 as we speak. I really like VS2017 a lot better than VS Code for web development.

[ryios]

I need to bite the bullet and start using typescript, VS has a lot of good support for it. Problem is, convincing my team to learn typescript..

Find for personal stuff though.

[avickers]

As far as (re)growing the community, I'm not convinced that features to the core library, such as single file components, will influence that much one way or the other.

To answer my own question from earlier, now that everyone has hopefully had a chance to think about it:

What's changed is a) the bar has been raised considerably for even a prototype/throwaway app and b) the front end world has matured considerably.

In order to make even a simple, demo professional quality KO application, a developer needs to be pretty experienced. So far as I know, there are no up-to-date scaffolding tools. Most KO developers seem to roll their own solutions, but that injects a level of both immediate overhead and technical debt into any project.

By comparison, the thriving frameworks all have CLI tools to easily scaffold out new projects with best practices development and deployment pipelines.

Type one command and you get the basic project created without necessarily needing to know anything about how to configure Babel, Webpack, Karma/Jest or a Service Worker. Type a second command, and you've installed a package wiring your UI library / design language of choice into your app.

Then it's a quick npm run serve and 5 seconds in and you've got yourself a modern app at localhost:xxxx to begin playing around with.

If the Knockout community is to recruit new blood, then it has to make an official effort at this sort of convenience. Otherwise, who is going to give it a chance?

It's not just a question of being easy for newer developers; but also, a question of being palatable for product owners and venture capitalists.

I think it's easily possible and, in fact, desirable for Knockout to preserve its versatility and usefulness as a foundation for bespoke frameworks; however, I think for the community to thrive there will need to be an officially unofficial "framework" via official tooling and plugins. A commitment to maintaining a CLI tool that spits out up-to-date boilerplate and an official package to wire up at least one of the major UI libraries is probably sine qua non for continued relevance.

This would allow developers to get back to experiencing the value prop of KO without any of the friction--like in the old days when all you needed was KO and jQuery to get started. Perhaps more importantly, it would leave product owners content that they're not going to necessarily be bearing all the costs of designing and maintaining both bespoke frameworks and build pipelines.

I just want you guys to think about one last thing:

Right now, when there's a new major version of, let's say, Webpack, some very small number of teams update their tools for the Angular/React/Vue communities and tens/hundreds of thousands of projects benefit automagically. In the every-team's-an-island Knockout world, then every team is going to be reading the documentation and paying for the migration at some point. Even an MBA should be able to figure out that that's not good. 🤣

Economies of scale: Open Source communities should embrace them; it's potentially one of their biggest advantages.

[nkosi23]

I think for the community to thrive there will need to be an officially unofficial "framework" via official tooling and plugins.

I totally agree with this idea, but, to me, this would be best achieved by building on top of the existing plugin ecosystem of knockout, not by inventing a brand new framework.

For example, you take some of the libraries developed by casey, you mix and match them with others (one for routing, one for this and that, one for a certain component-style, etc...), and you call that a framework. A pure marketing job if you see what I mean.

Because we need to propose multiple frameworks to people, otherwise, ko will be perceived as being opinionated. If you only propose one framework, it will inevitably feel authoritative. This is one of the reasons I feel that mixing and matching plugins to create marketing frameworks is likely the way to, because you have great flexibility to propose various styles and experiences, while remaining readable and consistent.

With this approach, people will naturally mature and start replacing plugins, and then modifying them, and then writing their own, and then talking more and more to ko-core directly.

The key will be investing in comprehensive and engaging documentations, and having a compelling website to discover these plugins and frameworks. That's the way I see it, just conveying my point.

As far as tooling is concerned, tko is providing this infrastructure (among other things), in an opt-in matter which looks perfect and nicely accomodates what seems to be the general consensus.

[agquick]

Thank you @avickers. Everyone who wants Knockout to survive needs to understand the point he's making. Choosing a front end library is very much a business decision. The last thing I want as a project manager is for my developers to be rolling their own front end framework unless absolutely necessary. Anyone who has joined a project of developers with a half thought out "framework" which turns into fragile legacy code knows what I mean.

I understand all the desire to be un-opinionated, but at some level there needs to be an officially unofficial framework as he said to create a level entry point that you can just pick up and go. It doesn't have to force people into a corner, but just needs to be enough to put hired developers at a level ground. I don't know if just providing an assortment of plugins on top of KO will get it there, but maybe.

I actually do think we can regrow the KO community. I'm extremely productive with this library. But like Andrew mentioned, the front-end JS world has matured drastically and the expectations developers (and managers) have for starting projects has just fundamentally changed.

[nkosi23]

There is broad consensus on the goals, I even we think we are all agreeing on them. I'm not sure if I'm misreading you but it sounds like you imply that there is an opposition between what people are saying in this thread.

To me there is none as far as the goal, is concerned. As far as the how is concerned, I see the view of let's build an official unofficial framework, and my suggestion of let's build several frameworks to give people choice while building on top of the plugin ecosystem.

I would tend to think that the fact that you oppose this implies that what you really want is an officially unofficial framework, that is actually kind of official...

In the interest of sustaining this productive discussion, I think it'd be helpful if you could elaborate on your proposal. Specifically, in my "how" proposal, I explain the various marketing and consistency challenges that I'm trying to address with this approach.

It would be helpful if you could address the specific points I bring up, and how you'd accomodate the concerns I raise regarding the sustainability and other various marketing prospects of the project.

For you repeat goals, but I don't think there is much disagreement as far as the end goal is concerned. Now it's really about the how and weighting the merits/gotchas of each method from a high-level strategic perspective. This is what I'd personally like you to do as far as your single-framework vision is concerned. I made a number of points to make my case, so it'd be productive to address them.

The only thing I see is the point raised by avickers regarding the mutualization of resources by focusing on building a single framework. But then, this doesn't address the question of the marketing implications of such a move for the project (what would make ko different / appealing, contributor risk if the larger API surface doesn't gain straction, how to maintain it, and would we even be able to compete of features / where does the feature parity ends, and what is the product visio., etc...)

That's a sincere request I'm making to you, this is not some sort of rethoric technic. I am interested in you breaking down your vision and confronting the various aspects and details I bring up. This will allow us to have a productive discussion and confront ideas / proposals / visions efficiently. Otherwise it quickly sounds like rambling and nobody is sure what we are talking about and what we are arguing for or against.

[avickers]

Doing it via plugins is pretty much exactly what I was hoping to convey. I was just already approaching wall of text length.

I hope that the community can maybe have some discussions now about the minimum number of official plugins needed to achieve a viable "officially unofficial framework," and I do feel like a CLI tool that scaffolds it altogether would really go a long way.

@nkosi23, I think we need to be cognizant of the very limited resources that the community has at present. Michael and Brian are already doing more than enough, so we will need other members of the community to step forward and commit to maintaining some of these other packages. I feel that as far as official plugins go, starting off with the minimum viable number should be strongly preferred. What each of us no doubt hopes will happen is that the community will step forward and create many more plugins. Community plugins that we absolutely should plug (sorry!) on the website when warranted, but we still should be cautious with what the community officially commits to support. Maintaining credibility with decision makers would be very important. If the project enjoys crowdfunding support and could hire full time staff, then the scope of ambitions could be scaled appropriately.

My hope with the "officially unofficial" approach is that it would ultimately prove to be illustrative rather than definitive, and it would allow people that wanted to expand in a specific direction or replace a specific library to have a common base of reference when writing their new plugin. If we could break the "framework" up into constituent roles, then hopefully it will be easier for the community to produce plugins that are easily interoperable with one another, if that makes sense.

From a marketing perspective, I think there's a big advantage to being able to say, "Hey, come back to us. All you need is 60 seconds to get started with a boilerplate KO app using modern javascript/TS and best practices." Knockout has a handful of things going for it vis-a-vis the true frameworks, and I really feel like stability of the API is one of them. While there is a new way to do many things, the fact is that 90% of the answers provided on StackOverflow (most often) by Ryan back in '13 and '14 are probably still copy and pasteable. That not only significantly reduces barriers to entry but also shows that apps can enjoy massive performance benefits over time thanks to the heroic work of Brian et al. without the need for complete migrations of project codebases. If we position ourselves right, KO should mean less technical debt than the major competitors; however, in order to achieve that, we will need to organize somewhat as a community around how we approach plugins in the early days of the reboot in order to help optimize our resources. IMO, at any rate.

Because opinionated frameworks cover a broader scope, they will more often find themselves in need of breaking changes. KO can mitigate that by better hewing to the wisdom of separation of concerns. I do think we should give some thought as to what are the common constituent parts of modern web apps. In what instances could the community embrace a consistent API for how such a part might interact with the rest of the ecosystem and in what instances is it better to just illustrate a particular design principle? Basically, what is the minimum level of consistency (opinion) needed to provide the best odds of interoperability to, hopefully, bring KO closest to enjoying the best of both worlds? Thoughts?

Lastly, I do think there is a discussion that should written on the corner of the chalkboard for pursuing another day, but if the community can come to some sort of consensus, then at some point there will be a need to discuss of both governance and solicitation of and allocation of resources. (It also may be possible to form partnerships and/or receive financial or in kind support from established companies--Microsoft comes to mind as a good candidate--but there would need to be a formal entity and structure in place to facilitate it.) @nkosi23 is not wrong about the importance of marketing, and there would need to be an official marketing strategy and budget if the project was ever to aspire to return to first tier status. Going into that now would be putting the cart well before the horse, but I think it would be very important to know how @mbest and @brianmhunt would feel about such an eventuality. They've done a great job as one man bands for a long time. I wouldn't dream of stepping on their toes.

PS: I apologize for the poor quality of my prose. SxSW means too much 🍺 and not enough 💤

[brianmhunt]

@avickers I think you and everyone here have hit on the essential points, and I think everyone is largely in agreement about what's needed for communal sustainability for the knockout projects, and these thoughts are all very welcome.

Knockout has generally been a resource strapped project, but it has strong technical bones (so to speak). The crucial question before us is what steps can we take to form a community that can turn those bones into a self-sustaining project with a vibrant contributor base.

I have predominantly focused on developing TKO's codebase, namely turning Knockout's bones into something more modern and modular. TKO has served me exceedingly well in that respect, and it has a huge number of benefits I'd like to bring to other developers that recognize the value of the Knockout style of development.

I'm open to suggestions on the next steps to make that happen. My list includes putting together updated documentation (e.g. tko.io), a CLI toolkit, community building, and partnership development. In a sense, I've put the cart before the horse with the code. I'm open to suggestions on what might be more effective, and contributions to these or in other ways are most welcome.

[avickers]

@brianmhunt,

Hmm... My suggestion would be to come up with a roadmap for the remainder of 2019 covering what you expect to realistically accomplish at current resource levels, as well as noting what's most likely to fall by the wayside.

Then maybe share with us which of these initiatives you are most enthused about, whether or not there are any blocking issues on said project(s), as well as what you are least looking forward to tackling. I know that you'd appreciate any help, but are there any specific pain points that the community could address to really do you a solid?

Do you have any sort of a design document for the CLI toolkit? I feel like that would answer at least half my questions.

@ryios,

The .NET world does seem an obvious place to pursue differentiation, considering Microsoft briefly adopted Knockout. MS seems to have gone in a different direction with Blazor and Web Assembly. (Blazor is actually the baby of Knockout's original author.) Are you familiar with MS's current ASP.NET strategy? Do you feel that what you describe would provide a meaningful alternative?

Do you feel that there a significant market of people looking to boot Javascript out of their build pipelines but that would prefer to still write their front end source code in TS/JS rather than migrate to a fully C# stack?

[caseyWebb]

I spent a good bit yesterday breaking out the tooling I use into a separate project yesterday. It's decently opinionated (and ever-evolving). Something I've considered doing for a very long time, but I didn't think there would be actual demand. It's not done or documented yet, but you can see the progress at Profiscience/ali.

Do you feel that there a significant market of people looking to boot Javascript out of their build pipelines but that would prefer to still write their front end source code in TS/JS rather than migrate to a fully C# stack?

no, and if it was anything else I'd want it to be properly compiled (go, rust, haskell, etc.). AFAIK dotnet core still needs the runtime to be installed on the system, doesn't it?

If you've got eternal NodeJS woes, can I safely assume you're on Windows? If so, I'd really really recommend adopting Docker into your development workflow. The WSL is great, but too slow in my experience. Docker works flawlessly once you figure out how to work it.

[avickers]

That's great, Casey!

I did a little playing around with a UI integration. I chose Semantic UI, and only got as far as the button component.

Still, I was able to turn

<div>
    Preferred flavor of spam:
    <div><input type="radio" name="flavorGroup" value="cherry" data-bind="checked: spamFlavor" /> Cherry</div>
    <div><input type="radio" name="flavorGroup" value="almond" data-bind="checked: spamFlavor" /> Almond</div>
    <div><input type="radio" name="flavorGroup" value="msg" data-bind="checked: spamFlavor" /> Monosodium Glutamate</div>
</div>

into

<button-group class="ui buttons" radio="spamFlavor">
      <button class="ui button" value="'cherry'">Cherry</button>
      <button class="ui button" value="'almond">Almond</button>
      <button class="ui button" value="'msg'">Monosodium Glutamate</button>
</button-group>

or this

<button-group class="ui buttons" radio="spamFlavor">
      <!-- ko foreach: { data: buttons, as: 'button' } -->
      <button class="ui button" value="button">{{ button }}</button>
      <!-- /ko -->
</button-group>

and individually toggled buttons as

    <button-group class="ui buttons">
      <ko-button class="ui button" toggle="bold">Bold</ko-button>
      <ko-button class="ui button" toggle="italic">Italic</ko-button>
    </button-group>

They are Web Components but not KO Components. I think the fact that they don't go into a child context will be convenient when it comes to most simple UI components. I'm hoping that the cleaner syntax and lack of need to communicate between hierarchical VMs will make it approachable.

It is possible to explicitly pass a binding context, of course:

<ko-button class="ui button" toggle="bold" context="$root">Bold</ko-button>

If the community has an overwhelming preference for another UI library or thinks that using vanilla Web Components is the worst idea ever, speak now or forever hold your peace. ⛪️ All other observations welcome too, natch.

[cosmoKenney]

I hate UI Libraries. That's the reason I don't use ASP.Net controls in my old web projects and why I don't use Razor on my new projects. I want to develop my views with raw HTML + Bootstrap.

As for a CLI, I've put a little thought into this recently. I think we need to start with scaffolding a project with lots of options. I.e. when you do a tko init command or whatever (tko new project) you should get asked:

• What type of project (spa or multi-page)?
• App entry-point name?
• What transpiler (Typescript, babel, or vanilla js/es6)?
• What bundler (webpack, or is there anything other than webpack? ;-))?
• JSX/TSX, or separate View/View-Model files?
• What CSS transpiler (LESS, SASS, ??)?
• What CSS Library (Bootstrap, what else?)?
• What package manager (hopefully everyone agrees on npm ;-))?
• It might be necessary (in fact i think it is necessary be the scaffolding would need to know how to organize assets, which will be different in each case) to know the web server technology too (.net core, asp.net, node, apache, ??)
• And so on.

That initial info should be persisted in the directory structure of the new project somewhere so that subsequent scaffolding commands can produce the right kind of file content.

As for sub-commands we would need scaffolding templates -- which would require community support to provide templates for all the different combinations of transpiler and bundler and so on.

Scaffolding sub-commands I can think of would be:

• New custom binding
• New filter (punches)
• New component
• New routeable component (see Casey's Router) -- which would require the route path and add the route definition along with the component files
• New page (for multi-page apps)
• New custom validator (knockout-validation) -- should specify async or not?
• New event (knockout-postbox)
• New middleware (Casey's Router).
• What else?

I would start this CLI project, but I don't know the first thing about setting up public projects on github. And it should really be in the ko-contrib namespace.

And I should add that everything else like UI Library Style and a whole host of other things should come in the form of either plugins to both the CLI and maybe as npm packages that you install or they just aren't there if you don't want them).

When it comes to JSX support I could see a webpack plugin doing some sort of pre-processing to convert the JSX to separate in-memory files sort of the way that the typescript plugin transpiles your ts files to js then hands them off to webpack. I think it would be a shame to do a custom pre-compiler like angular's thing.

[caseyWebb]

@cosmoKenney If you want to develop in Profiscience/knockout-contrib just fork it and add a package and I can deal with the publishing/maintenance

Is anyone opposed to me snagging the knockout-contrib org on NPM for that repo?

[avickers]

@caseyWebb,

I think it would be a great idea to put these emergent projects inside of a common org.

@cosmoKenney,

I used to use Steve's generator-ko to scaffold projects with KO & TWBS, but one of the first things I would do with new projects was to copy in a js file containing a dozen or so custom bindings that I had written to stitch up Bootstrap components with KO. Do you do something similar or??

Would a collection of custom bindings be preferable to a bunch of web components?

[cosmoKenney]

@avickers I tried generator-ko a while back. But now I just code most of the stuff by hand -- but would love to have a scaffolding cli.
As far as bootstrapping a new ko project, I do have 10 years of worth of ko related utilities, custom bindings, filters and so on that I copy to every project.

[cosmoKenney]

@caseyWebb, no problem for use of knockout-contrib as far as I can see.

[ryios]

Imo, using a UI framework that operates client side is a lot different than using ASP.Net Webforms, way different.

Imagine you have a UI Framework with everything you can think of sitting on top of bootstrap 4.

• ko-button
• ko-datepicker
• ko-calendar
• ko-row
• ko-col
• ko-grid (container)

etc etc etc.

But it's all built on SASS with mixins and config/variable files and an easy way to extend it.

Then you've got a prebuilt UI system that you can highly customize and add on to.

Secondly, if you want to upgrade to bootstrap 5, you don't have a bunch of class="blah" all over your application that you have to go fix, you can just update the UI system and your app just works magically.

In a way, if you do this, you are building a style guide with a set of standards you are adhering to as you build your app to make it highly updatable, easy to manage, and clean.

If you build a style guide on top of it, demonstrating how to use every single component and how to customize them and or add new styles to the SASS build, etc etc etc, then you create a standard way for others to do UI work on said system.

Avoiding having people override .panel-heading globally and screwing up everything that relies on bootstrap down the line.

Can't tell you how many times I have to reload bootstrap inside a specific element to override people who overrode bootstrap styles, DIRTY dirty stuff.

Working independently, alone, sure, do you're thing.

But I think on large teams of developers all doing UI work, having some kind of Style Guide and UI system is invaluable.

We don't want 6 UX engineers doing something 6 different ways.

I cringe when I look at css on some applications and you look at the annotations and see 8 people worked on it. One guy has a class called "sidebar-wrapper" and another guy decided to just target "navbar-default" and override bootstrap, and another person added a bunch of global .panel overrides with no thought of any projects coming down the line that might want to use bootstrap panels without being specific to the previous app page...

Things get so fragmented.

I'd love to see a feature rich UI system built on top of knockout that is easy to clone and make changes and additions to with a cool style guide.

In a way, similar to the angular-material project, but for knockout.

[avickers]

Thanks, Ryan. That's extremely helpful.

So if I understand you correctly, the best thing for me to do would be to create a convention for common UI components.

Instead of

    <button-group class="ui buttons">
      <ko-button class="ui button" toggle="bold">Bold</ko-button>
      <ko-button class="ui button" toggle="italic">Italic</ko-button>
    </button-group>

It would be

    <ko-btn-group>
      <ko-btn bool="bold">Bold</ko-btn>
      <ko-btn data-bind="value: italic">Italic</ko-btn>
    </ko-btn-group>

Such that if someone imported a Bootstrap integration, that integration would apply the pertinent classes behind the scenes, and in order to migrate to Material Design, they'd merely need to import a MD-based package instead. The only other difference would be changing the ko.plugin() initialization to spin up the correct helper libraries, define theme colors in the correct schema, etc.. Does that sound right?

[cosmoKenney]

@ryios when I first started working with bootstrap in a ko project i tried to build some standard components but quickly realized I had to have provisions for extra classes and so on like the d-* or m/p-* classes so I could augment the layout of those as necessary. So I ended up trading one attribute (class) for a custom attribute (extra-class). And being a small team, when I do bring in an extra resource, I don't have the bandwidth to teach the new guy/gal how to use our ui library. So they end up doing their own thing anyway.
There is a lot to be said for being able to go google "how do I do * in bootstrap 4".
And as it turns out, bootstrap is kind-of a low level ui library already. And this is precisely why I don't like any of the MS Web UI technologies. I have to go to msdn every single time to figure out how to control my resultant HTML. It is crammed with custom attributes and could be so much easier to learn. And in the end all it's doing is keeping us from having to learn HTML??

I think you are right, though for larger dev shops where there is a manager or architect or lead who can create and document the usage of a custom ui lib, then it makes a lot of sense as long as it saves time. But for sure provide it as a plugin to whatever KO based framework we ultimately come up with. ;-)

[caseyWebb]

@ryios when I first started working with bootstrap in a ko project i tried to build some standard components but quickly realized I had to have provisions for extra classes and so on like the d-* or m/p-* classes so I could augment the layout of those as necessary. So I ended up trading one attribute (class) for a custom attribute (extra-class). And being a small team, when I do bring in an extra resource, I don't have the bandwidth to teach the new guy/gal how to use our ui library. So they end up doing their own thing anyway.
There is a lot to be said for being able to go google "how do I do * in bootstrap 4".

100x this. I get the appeal of UI libraries, but unless it's extremely well documented and actually supported, it becomes loads more of technical debt than it's worth.

[avickers]

If I understand, Ken was trying to use KO Components. In that case, KO was replacing all the components with templates. Ken needed to create a mechanism for conveying helper classes from the KO components to the templates, and it was more trouble than it was worth. Yes?

Let's pretend I said Bootstrap instead of Semantic UI for a minute.

What I've proposed is using vanilla web components. There are no templates. The nodes don't get replaced. You can apply any helper classes from the Bootstrap library directly to them and they will work as expected. You can use the data-bind attribute to do anything, and it will work as expected. All is mostly does is provide some shorthand convenience attributes to reduce verbosity for the most common scenarios. Instead of having to type out data-bind="value: foo, it becomes possible to just type value=foo. I realize that punches let's you just do value={{foo}}. Mine would also manage the active class, such that you didn't need to bother with a css or class binding. (I realize Bootstrap might use jQuery or something to accomplish this, but it will not automatically sync with your VM state.) Less to type repeatedly, and less repetitious stuff cluttering your html. Less to scare away newcomers to the library.

I'm not setting out to create a new UI library, just add some syntax sugar. Do we like sugar, or nah?

[ryios]

Who doesn't like sugar, it's just sugar is bad for you, m'kay.

[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?

[agquick]

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.

[myuseringithub]

@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.

[agquick]

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. (#2500) as an alternative to #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.

[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.

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

[agquick]

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?

[agquick]

@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😄