knockout
knockout copied to clipboard
knockout
What is the future of knockoutJS?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
@BooleT37 Indeed. Modularization is why I rewrote Knockout as TKO with ES6 modules.
@brianmhunt I'll look into your project. It looks just like the thing I need.
@BooleT37 I use Knockout, and Knockout-validation in conjunction with webpack. They work just fine together.
Isn't Webpack operates well with AMD and window globals? Webpack's:
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.
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.
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.
@Dmitri-Sintsov Knockout isn't a Microsoft library. It's entirely independent.
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.
@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
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.
+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.
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">
@Dmitri-Sintsov Have you seen Knockout Punches? Using it, you can do this:
<input value="{{myTitle}}">
Or
<input textinput="{{myTitle}}">