Talk:Knockout (web framework)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Talk:KnockoutJS)

Maintenance and rating of JavaScript articles[edit]

Concerning editing and maintaining JavaScript-related articles...

Collaboration...[edit]

If you are interested in collaborating on JavaScript articles or would like to see where you could help, stop by Wikipedia:WikiProject JavaScript and feel free to add your name to the participants list. Both editors and programmers are welcome.

Needs HTML equivalent of JavaScript sample code[edit]

JavaScript sample in the article is OK but really needs HTML to show the binding in action from the HTML side. — Preceding unsigned comment added by 2600:1700:D591:5F10:7123:EFE8:AEC2:3F5B (talk) 04:54, 13 December 2019 (UTC)[reply]

Where to list JavaScript articles[edit]

We've found over 300 JavaScript-related articles so far. If you come across any others, please add them to that list.

User scripts[edit]

The WikiProject is also taking on the organization of the Wikipedia community's user script support pages. If you are interested in helping to organize information on the user scripts (or are curious about what we are up to), let us know!

If you have need for a user script that does not yet exist, or you have a cool idea for a user script or gadget, you can post it at Wikipedia:User scripts/Requests. And if you are a JavaScript programmer, that's a great place to find tasks if you are bored.

How to report JavaScript articles in need of attention[edit]

If you come across a JavaScript article desperately in need of editor attention, and it's beyond your ability to handle, you can add it to our list of JavaScript-related articles that need attention.

Rating JavaScript articles[edit]

At the top of the talk page of most every JavaScript-related article is a WikiProject JavaScript template where you can record the quality class and importance of the article. Doing so will help the community track the stage of completion and watch the highest priority articles more closely.

Thank you. The Transhumanist 01:11, 12 April 2017 (UTC)[reply]

Unsubstantiated Claims and Shortcomings w.r.t. trade-offs.[edit]

Many if not most of the so-called "client frameworks" make claims that are simply either untrue, or impossible to prove - which to most of us, amounts to the same thing. KnockoutJS is no different in that regard, and it's very frustrating to try to decide which framework to use when we are faced with claims such as the following (in this article):

  • "These features streamline and simplify the specification of complex relationships between view components, which in turn make the display more responsive and the user experience richer."

The previous compound statement is NOT a fact-based assertion. It is more like marketing material. For example, I do not find that adding KnockoutJS to my client-side code simplifies ANYTHING. To the contrary, it adds another layer of complexity and an additional dependency with its own substantial learning curve. It does not make the "display more responsive" ... that is 100% bunk. It's a tool that interprets embedded language extensions, and then generates JavaScript. Therefore, I can and usually do write script that executes just as fast by hand. In no case is it "more responsive". It can't be, because it's just javascript. Further, the entire so-called "User Experience" is in no way defined by the framework. The framework is just a tool that is built upon a lower level, in this case, javascript and HTML. It has nothing whatsoever to do with the actual UI design. Any responsive design that can be done using KnockoutJS, can be done with plain vanilla Javascript and HTML objects. That is a simple fact, and I do it daily as part of my profession. .getElementByID() is not obsolete.

In summary, none of these claims are true. LnockoutJS does not "streamline" the specification. It does not "simplify" anything. (Quite the opposite) It does not make the display more responsive, and it does nothing to add or take away from the "User Experience" (aka, the 'user interface' to those of us who were born prior to 1995.)

I am not solely going after KnockoutJS here. Far from it. This article just set me off for reasons mentioned above. I am merely a veteran developer struggling to make sense of all these add-ons and questionable frameworks, that truly, at the end of the day, just make my life more difficult. Tracking all the dependencies, cross-talk and version updates alone is reason enough not to use them. And further, none of them really get to the heart of the toughest issue - which is integrating back-end (server) objects and code to the front end, responsively and without disconnect. The current state-of-the-art is not a pretty picture since it takes 4 to 8 times as long (and as much code) as it did to print a simple array of objects to the client's window as it did 20 years ago. This is what happens when you refuse to admit that you've gone down a bad path. Everyone who follows, pays.

Cheers. 98.194.39.86 (talk) 15:08, 8 December 2018 (UTC)[reply]