What is Reddit's opinion of
KnockoutJS?
From 3.5 billion Reddit comments
➔ KnockoutJS website
By popularity on Reddit, this Service is:
66 reviews of this app found across Reddit:
Not a joke. They have become known as MV* frameworks. Some are MVC. Some are Model, View, View Model (MVVM). Some are Model View Presenter(MVP) etc. A popular JavaScript MV* framework is AngularJS by google, or KnockoutJS by Microsoft.
Here is a good write up from Smashing Magazine.
There has been a recent trend in Web Development to build Single Page Applications or SPAs. This type of architecture essentially just uses the back end to serve up data via AJAX requests from the browser. This gives a desktop app feel to a web application (think gmail). This also means that a lot of the logic is now client side. There arose a need to better organize client side code, thus MVC made its way to JavaScript.
Neither. When I'm looking through sample code, I'm either trying to learn the API or solve a particular problem (how do I draw a 3d model, what does a particle system look like)? Not just the basics, but more advance topics as well.
As an example, Knockout has both a list of basic examples and more advance topics, as well as a very nice live tutorial.
It doesn't need a super fancy GUI, just a list of well-named directories that include separate topics will do. Ogre does this, but not very well. The directories aren't clear and the code needs commenting.
And comment your code! Ideally, say what you're doing, why your doing it and what are the alternatives you could do here.
And error handling! Most sample writers ignore error handling, or worse, wave their hands at it. Have a sample where you show how errors are returned and what they mean.
Components look interesting: http://knockoutjs.com/documentation/component-overview.html
Somewhat like React.js but with an overly string-based syntax (e.g. data-bind="click: handler") instead of named types/properties (e.g. onClick=this.handler). KO's syntax for passing properties to custom components for example: http://knockoutjs.com/documentation/component-custom-elements.html
Kudos to the documentors. Lots of JS frameworks/libraries really should have quality documentation like KO.
I'm not really seeing a new take on MVVM here. The special CSS classes in the HTML are data binding declarations (which btw is awful, that's what HTML5's data-* attributes are designed for), then you create a model in Javascript, and notify Horn of any changes you make in order to update the DOM.
So the view is HTML, Horn is the View Model minus change notifications and commands, and your Javascript model is the Model plus change notifications. That's just standard MVVM except the M and V are doing some of the job the VM is supposed to.
TLDR: knockout.js
If you are going to use classic JS to dynamically manipulate the DOM, you should use the built in element builders instead of trying to add them yourself by writing markup:
In this example, I've gone and created objects to represent the various elements you want to create. You don't have to do what I did, and I could have done more, but this should be more than sufficient as an example. You want to create the elements with the supported document.createElement/TextNode methods and then manipulate them as I did.
You also don't want to be using document.write() since it is very rarely going to work out the way you want it to and gives you less control over the page and where the elements get appended to and is much harder to style.
EDIT: Also, I would recommend using knockout.js if you want an easy way to manipulate the DOM dynamically instead of doing it yourself, which you should generally avoid.
Well this is a comment graveyard. Seriously, though, popularity is hardly a good basis for choosing a library or framework. You wouldn't choose Java just because it is more popular, would you?
The best thing to do is to try a few and see what works best for you. That's what I did, and I ended up with knockout.js. YMMV. There's certainly no shortage of options.
Check out Knockout.
Basically, the goal isn't really direct two-way binding, it's a) a precise and managed translation of a view-model's current state to a view, and b) registration of events happening in the view and translating that back to meaningful state and data in the view-model.
In my experience, true two-way binding is probably never what you want, because that couples your view to your view model and vice-versa far too tightly.
The story behind this:
We have an app with a very big state tree, and performance starts degrading. We started noticing that some selectors are recomputed more than necessary. Since these selectors return new objects, they break PureComponent prop checking and caused a lot of useless re-renders. In this example, our data is organized into a tree structure:
{ tree: { node1: { title: 'HTML' }, node2: { title: 'CSS' }, node3: { title: 'Block elements', parent: 'node1' }, node4: { title: 'Selectors', parent: 'node2' }, node5: { title: 'div', parent: 'node3' }, }, currentNodeId: 'node5', }
Based on currentNodeId we need to generate a breadcrumb: HTML -> Block elements -> div. This requires traversing the tree through its parent to the root. We couldn’t find a way to efficiently create a selector that only recomputes when the related node changes. And our tree is big (10,000s of nodes).
Then it dawned on me that accomplishing this requires the selector’s dependencies to vary dynamically, depending on the currentNodeId and what each node says their parent is (impossible with Reselect, so we can’t build a solution on top of it). This led us to create this library :D. Since we have 300+ selectors already, this library must be interoperable with Reselect.
I found that a lot of people also asked about the same/similar scenario, so we decided to open source our solution. However we don’t have plans to support/maintain it beyond our use cases. Nevertheless I hope the React/Redux community can benefit from this. ^_^
> There is not a day that passes that I don't mess up a binding or a piece of logic because I expect a variable to be a value and it is a function.
http://durandaljs.com/documentation/Binding-Plain-Javascript-Objects.html
> Binding using data- attributes encourages you to move your logic into the html code where it is all but untestable
Only if you're too lazy to code a property for it.....
> Why aren't you doing your filtering in the model?" he asked. Quite right, I should be doing it in the model and I, indeed, refactored the code later to do that.
Why not do it properly the first time? Writing logic like that in HTML is harder and takes longer anyway.
> Knockout supports creating components but these are rendered at a non-deterministic time. This means that if you want to do something after the component has rendered you're pretty much left guessing.
This is actually a pattern also recommended when working with the client-side MVC framework Knockout. Here is a page in the documentation explaining it.
> Is that the concern of the json spec though?
Yes.
This was written in a time when, for the sake of backwards compatibility, IE butchered HTML comments with parsing directives. When script blocks started with //<[CDATA[ because it was impossible to know whether your browser would use XML mode to process XHTML, if it would fall back to SGML, or do some undefined (and likely terrible) thing in between. When javascript frameworks put directives in comments. And that's just the stuff that happened in my (relatively short) time as a web developer.
There's nothing wrong with disagreeing with Douglas Crockford, but his decision was rooted in a real concern that actually occurred. He's no idiot.
I'd avoid storing state 'in memory' on the server unless there's no other option. The configuration for the survey can be cached, but you'll need to identify cache invalidation points.
If you're interested in capturing state (e.g. the person is at question x), then you should store the state (partial complete survey) in the database and if necessary, use a state machine to model the progressions (e.g. return current question, progress to next question and store the answer).
Alternatively, the simpler option is to store the intermediate state client side. Have an API method that returns the configuration (question, possible answers, other 'actions' or 'conditions') for the survey and model the survey and progression in a JavaScript application view model. KnockoutJS is pretty good for creating a JavaScript application for a single page without having to build a full SPA. +1 for KnockoutJS validation
I've not done much in this area, except a small project that used knockout.js. http://knockoutjs.com/ It was very easy to pick up and has some good tutorials out there. Basically you use flask, or whatnot, on the backend to serve up json, which is parsed by the browser and put into pretty form for the user.
Knockout does two-way data binding and templating like Angular does, but that's about it. Angular is a bit more "complete", with its service architecture, dependency injection, filters, and ~~directives~~.
edit: Knockout introduced custom elements a few months ago, which is similar to Angular's directives.
In Knockout if you don't like inline logic in the templates (views) you can instead use a computed observable on the view model (more like a controller). So in this example you could use the first code example rather than the second.
Some similar projects:
Many different groups have been working towards this for the last 6-12 months. Meteor clearly has a lot of money and engineering talent to use though.
Aside: What's the deal with "realtime?" It's not realtime at all. People should call it "auto-synchronizing" instead.
I just discovered Knockout, a Model-View-View Model framework. It might not be the best framework, but it has an amazing interactive tutorial that helped me understand a lot of concepts for javascript frameworks in general. I used it to throw together the first real site I've built on my own time in 10 years, and it was a lot of fun!
You should probably get the basics of jQuery down first though, at least understand the selectors and how functions are being used.
You could look into the MVVM approach to UI design. http://knockoutjs.com/
You'll also want to make sure you separate your templates out from your Javascript. So have some sort of templating language (like mustache) to do the html rendering.
>Also, can I inject HTML from a file?
Vue makes that easy with bindings, but short of completely retooling, give Knockout.js a try. You can use it to bind and inject HTML, enable 2-way data binding on your form fields, and even do validation. It will also enable you to do all of your checks and DOM updates without relying on jQuery for your DOM stuff. While it is an older library, it works perfect for situations like yours and you should be able to learn it in just a couple hours. It is a very small MVVM library that is perfect for managing the Form UX.
The way you were setting the text value was incorrect.
According to the documentation the text value needs to a observable, and set with a function. http://knockoutjs.com/documentation/text-binding.html
I made fork of it that works here: http://codepen.io/Stevenwithaph/pen/rjxXaP
I added some comments that should make it clear what I did to get it working.
If you have any questions let me know.
Depends what you're looking for. I think Knockout is quite nice for cases like this, just because it doesn't do too much. It gives you the core data-binding (transforming your JS data into HTML on the page, and connecting HTML events and input back into your JS logic) but doesn't dictate structure or bring in more complicated features (like client-side routing etc), and doesn't need build tools or any major set up at all.
It's not the right choice if you're looking to build something huge, or if you're aiming to hugely commit to client-side-only apps, or anything like that. If your goal is to learn how these frameworks actually work though, I think starting small with these tools and understanding the core functionality is the way to go. If you pick up something too big and too magic, you end up learning the framework much more than learning the concepts behind it. Not bad for getting started with that framework, but terrible for being able to use others in future. Playing with the principles and simpler tools is much easier.
Even better, there's an extremely easy Knockout tutorial at http://learn.knockoutjs.com that will straight away get your writing working code with zero setup, so you can see how this all holds together. TBH even if you're not going with Knockout, it's a good way to get to grips with the basic principles.
No love for Knockout here yet?
I love that it lets you do what you want. You don't have to "play by the rules" as much as you do with Angular, etc.
If you just need some simple two-way binding for a small project, it's super easy to set up. If you need something a bit more complex (inheritance, etc.) you can accomplish that through the usual JS techniques, and then utilize Knockout within your classes to handle the two-way binding aspect of things.
Honestly, after the initial learning curve, it's pretty awesome.
edit: wtf is up with the downvotes? this is an opinion thread - if you want to debate the points I made about KO, then do so...
Thanks! I'd realized the connection to FRP (I was originally inspired by Knockout.js's computed observables, and it's not hard to jump from there to FRP), but I hadn't thought about netwire. I'll have to take a look at it, and see how I would implement the same using what it provides.
It really depends on what functionality you expect. For example angular is MVC, but you don't have to use it in it's entirety. You can pick parts of the samework (for example databinding and ajax) and only use those on server generated pages.
Another options is KnockoutJS which gives you really great databinding and again works well on server generated pages. I've used it a ton.
Other than that the libraries are all function specific for example:
jQuery: A great toolset for interacting with the dom and handles cross browser issues.
PhantomJS: is not something you would use on a site to enhance it, it's a headless browser (IE - no ui) and is mainly for testing and automated scripts.
ThreeJS is a 3D library and great for situations that rely on a lot of graphics.
Underscore: add functional programming techniques to javascript via new functions.
If you want to use JS as an enhancement tool, first you have to figure out what you want to enhance and why. You do want to add animations? Use CSS 3 animations (which work with any framework or raw javascript). Do you want to update the page on the fly via ajax? You can do that in just jQuery or use Angular for databinding and ajax and get testability and a good structure.
Pretty much every mature framework supports forms. I'd say Ember is a safe bet, considering Angular will move to 2.0 and make a lot of breaking changes.
If you are used to MVVM try Knockout, even though it's not nearly as complete at Ember, you have some freedom to implement the missing parts and MVVM might be better for managing complex forms.
Knockout is simple (in a good manner) and does what you described. I'd give it a try.
If you need additional features like routing, you can add, say, http://sammyjs.org/ to get the job done.
This is great advice. I'd like to addon, as plushoxy said, Angular is for complex apps where it may get more in the way than be helpful for simple things. I've done great things with it, but it most excels when you're making a "one-page" app where there is only one page load.
If you want to delve into a js framework that is super light-weight and unobtrusive, I would recommend checking out KnockoutJS. http://knockoutjs.com/ This gets you started with all ideas concerning MVVC frameworks. Angular can be daunting for someone just getting started, especially when you start to make custom directives and filters. Then you jump into the ideas of services and factories...
Hi! I like Backbone a lot, but given what you've described, I'm not sure it's the right tool for you. I think Backbone won't have much to offer you if you're not making an SPA--and, importantly given your needs, Backbone doesn't have any built-in support for data-binding to the view. There are various plugins that support this (I like Stickit).
If you just have a page, and you need the data and state of controls on that page to be automatically updated based on the result of server reqeuests, I think that Knockout might be a better fit. I don't use it myself (it doesn't play nicely with Backbone, though again, there ways of making it work). And Knockout isn't a full MVC framework--but again, it doesn't sound like you need one.
What Knockout excels at (from what I'm told/have read) is updating views based on model changes, and vice versa. From the looks of it you can easily fetch/save data between the view model and back end using jQuery.ajax (or whatever else you want).
Go ahead and check that out. You could certainly make this work with Backbone too, of course, and I'm happy to give you some pointers there, but it's worth spending a little time to try to start with the best tool for the job.
HTH
The easiest is knockout.js.
You just return all your responses in JSON and call them using either Flask-sijax, or just a regular jquery $.ajax function.
In the example on the main page, just replace this.tickets = AjaxResponse()
Super simple example:
I'm a little late to the party, but if anyone still stumbles on this, I thought I'd share my two cents.
The article assumes that data in the view should directly correspond to the model. The issue with this is that it often doesn't. In reality, your view state should be managed independently from the data being represented in it. This is often called the Model/View/View-Model pattern. The View-Model represents the current state of the view, and the data currently in it. I like to think of it as an API for your view - you don't want to set the value of a text input, you just want to set the value the text input is reflecting. This also makes your UI logic much more testable, because you no longer need to directly manipulate the DOM in order to control your application.
I wrote up an explanation of how to achieve simple, well-managed, two-way data-binding using vanilla, IE-6 compatible JavaScript: https://gist.github.com/austinhyde/4321f22a476e1cbee65f
Spoiler: It's basically Knockout
It looks like the paypal js api has some markup you can inject into your pages to do some of this for you: https://developer.paypal.com/docs/
You can use a library like (KnockoutJS)[http://knockoutjs.com/] to bind your markup to javascript objects if you want to conditionally display ads. This seems to introduce more complexity than you need right now though where you can just add a simple jQuery hide to your ad wrappers.
EDIT: Careful with just hiding the ads with scripts, I'm not sure what your advertisers' policies are with regards to that.
Backbone does have data binding as one of its goals but does so in a completely different way.
However, Knockout.js does pretty much the exact same thing the same way. He mentions knockout as an alternative however, so I'm assuming this was made to address something knockout doesn't? Or to just be a light weight competitor. I'm not familiar with either to be able to really tell.
Funnily enough I typically take the exact opposite approach. Instead of having pure Javascript that doesn't know about the DOM, I have a pure DOM that doesn't know about the Javascript. Not that I advocate either approach other than personal preference though.
The way it works is that instead of getting and setting values from html elements directly you create an object called a view model. The view model has fields that match the html elements on the screen. Through knockout you can bind those fields to elements so you don't have to manually update html elements directly. What I mean by that is let's say I want to update the value of a textbox that is supposed to hold a persons first name. Instead of updating the textbox I just do viewModel.FirstName("bob") and that automatically updates my textbox and any other html elment binded to the first name field.
Take a look at this simple example http://knockoutjs.com/examples/helloWorld.html
Frameworks provide scaffolding for writing complex applications. You're right; it's easier to do simple things by wiring up your own event handlers and managing all your state without any particular organization. But if you end up building anything particularly complex, you'll naturally re-invent the patterns that the frameworks have already implemented.
Take Knockout, for example. Knockout is very small. You could read all the documentation in at most a couple of hours. But Knockout provides a concept - the idea of the observable, mutable cell - that doesn't exist in plain JS. And it's a very useful primitive for building complex applications. Knockout encourages you to organize your application state so that the DOM is a mirror of the data in your observables, and if you want to change the DOM, you do so by changing the data in the observables.
We could debate the relative merit of this approach compared to the virtual-DOM approach of React and Vue or the "everything but the kitchen sink" approach of Angular. But all of these frameworks provide something that is useful for complex applications.
I can't answer your question with 100% certainty, and hopefully someone else with more experience chimes in, so I'll just say this: from my experience, "Observable<whatever>" are mainly used to work with the GUI controls to display the objects and to track changes to them.
I just did a quick search for ObservableArray and came across this:
http://knockoutjs.com/documentation/observableArrays.html
>Observable Arrays
>If you want to detect and respond to changes on one object, you’d use observables. If you want to detect and respond to changes of a collection of things, use an observableArray. This is useful in many scenarios where you’re displaying or editing multiple values and need repeated sections of UI to appear and disappear as items are added and removed.
It's just another Javascript view/templating language.
Page is assembled by components such as https://www.berkshireblanket.com/file/v12/widget/webContent/content/m10005.html
or
Google gets it.
As far as I can see, you have an array of tasks. Then, when you click on the button, the code will pick one of the values from the array, displaying its content on the input, right?
The idea is really simple, but your implementation makes to have the javascript and the HTML too coupled. Nowadays, there is a lot of javascript libraries or frameworks that allows you to implement your idea in a more maintainable and easy way.
Check this link: https://jsfiddle.net/ykgk8f9j/2/ there you can see a sample I made, based on your ideas. This code uses AngularJS. The code is really simple, and I only have an Angular controller with the different options ($scope.options) plus a function ($scope.setTask) that sets the selected value (in the selectedTask property) randomly from the array of options. I'm sorry for the confusion with "options", "quests" and "tasks", but I'm not sure how to call them.
As you can see, the HTML just renders all the available options in the $scope.options object, rendering F2P Skiling and F2P Questing. Then, it shows the value of the selectedTask (at first, as we don't have a selected task, we simply render "Without task") and a button that executes the setTask function. Is really simple.
There is a lot of javascript libraries and frameworks that can help you to implement the same ideas. I like a lot http://knockoutjs.com/ for simple tasks, and https://angularjs.org/ for more complex tasks, as it includes services, directives and http calls.
I hope the sample can help you. Try to forget about coding manually the javascript modifications of the user interfaces, as you were doing. You will finish having a bunch of spaghetti code, making your app less maintainable.
Regards and good luck
If what you like most was data binding, but you're otherwise happy with Backbone, then look into integrating Knockout (http://knockoutjs.com) into your app. Its just a data binding layer. Backbone is the view model in the MVVM pattern, so you should be able to use Knockout view models with Backbone views. There's also a project called KnockBack (https://kmalakoff.github.io/knockback/) which is a combination of Backbone with Knockout data binding.
I don't disagree that currently JSON can be evaled into a Javascript object but that isn't guaranteed for any future versions of either. That is why it's based on and not a subset. Right now the issues arise more so when you want to programmatically generate a Javascript object that isn't valid JSON.
For example a Javascript object can have functions and undefined both of which are invalid in JSON. This was a problem for me when I was using KnockoutJS and I wanted to generate the Javascript object you use to configure it on the server side in my Rails app. That Javascript object was going to have to include a function and so I couldn't use standard JSON libraries to generate it. I do understand that this is a highly irregular thing to do but without going into a ton of detail that was the best option I had.
I asked around elsewhere and I was directed to Knockout, which seems to completely fill my requirements. It has built-in directives that can bind to any DOM event (click, mouseout whatever), and that's just what I needed.
Haha. Knockout JS is a lightweight MVVM framework that combines document-driven data bindings with reactive programming, and lets you compose web applications with Polymer-esque custom elements, even in legacy IE. But don't take my word for it - why not take a look at its excellent documentation?
I like it!
One quibble, looking at the documentation for memoized selectors, it feels very verbose to provide and specify each dependency. I wonder if someone could steal the automatic dependency detection technique from Knockout's computed observables.
knockout would also be an excellent choice for something like this. If you've ever done MVVM, or any sort of data-binding, knockout is very simple. It's not as heavy as angular, but still very powerful. Message me if you'd like more details.
Create a computed observable in knockout http://knockoutjs.com/documentation/computedObservables.html
In your markup set up data binding to bind to the computed observable. When any of the observable referenced inside change it should cause the computed to update.
Edit: Here's a simple fidle. https://jsfiddle.net/fe37y76h/2/
Not a ton of details, but I'd recommend checking out knockout.
It's a MVVM library (not a framework), does pretty much one thing (2-way data binding), can be easily incorporated into any project and has a low learning curve.
I'd also recommend using knockout's mapping plugin which takes care of mapping your json data to your view model.
/u/clarutte has the right idea. The reason it is not working is because you are calling ko.applyBindings() before the DOM has finished loading the body, specifically the KO bindings <input data-bind='value: firstName' />
You can either wrap it in a document ready handler, or by placing script.js in the footer.
More info in the official documentation under "Activating Knockout*"
I work on a very JS heavy multi page webapp. We use knockout. I can't comment on whether or not it's better or worse than react, but I have found knockout when used with komapping to be a really clean and powerful way to do JS heavy work with two-way data-binding without having to rely on a full-blown framework like Angular.
With that said, React may be a better choice, but I thought I'd provide you with another option in case you wanted/needed it.
I haven't decided about open sourcing it yet. I plan to open source some of the custom components that I'm building for it—particularly a WebView–Node.js bridge that enables something along the lines of RPC calls—but I'm on the fence about whether or not to release the entire project source.
That said, the GUI component is a WebView running custom CSS to mimic native UI. I'm using Knockout.js for the data-binding, and I'm working on a custom bridge between WebKit and Core Data for data storage.
I found this tutorial very helpful:
http://blog.miguelgrinberg.com/post/writing-a-javascript-rest-client
And I liked the knockout.js tutorials, here: http://knockoutjs.com/
But it is the only one I have used, so take it all with a grain of salt.
Facebook's been borrowing a lot of successful ideals from the functional paradigm (immutability, statelessness, etc.) and 'porting' things from Clojure into JavaScript. React and Immutable are two great libraries that can change the way you think about JS development and scalability. The only real downside to React is that it's pretty hefty, but if you considering that it's emulating it's own DOM and doing high perf diffing once loaded, it's no surprise. If it's a medium-to-big application React is the way I'd go. If it were some small (and will stay small) data binding requirements where I need a lot of browser compatibility, I'd probably just go with Knockout over Angular since the mark up is cleaner than and the checking isn't dirty. With throttling Knockout's really performant too.
As others have said, it doesn't sound like a full on SPA, so I would avoid both Ember and Angular. They are both big, monolithic frameworks that are better suited for when you have a large SPA to build.
Instead, I recommend trying smaller libraries that are better suited for the specific type of functionality that you are trying to implement. Something like React or KnockoutJS would be good ones to try. Backbone is also a good starting point and you can use it with both React and Knockout, if necessary.
Well... That alleviates the need for routing and most of what Angular provides.
I would then suggest you look into knockoutjs for adding some required organisation of your data flow and templating. Use jQuery for doing some ajax so that everything is not a page refresh but don't use it for directly manipulating the DOM (let knockout do it, it won't spaghetti your app like jQuery).
Had you made an SPA you'd need a router and stuff but you can avoid all that now.
Knockout is stable, mature, well-supported and not powered by hype. On top of that, the documentation is top-notch.
I am a novice, but I have mucked around a bit with jquery + flask and it works really well. So well indeed that I wonder why people even use jinja.
Here is a great tutorial to get you started:
http://blog.miguelgrinberg.com/post/writing-a-javascript-rest-client
And here are the docs for knockout: http://knockoutjs.com/
Knockout basically is a javascript library that provides an easy interface to render data. The tutorial online at the knockout website are very good and easy to follow.
Also check out http://jsfiddle.net/ if you have not already. It is a good way to test code as you go and dig up examples from people who have already solved your problem.
Angular was a bit heavyweight and impenetrable for me as a starter, so I went with Knockout (and JQuery of course) and manual subscriptions.
So I can have a bit of code like this to update the right div whenever income changes (simplified):
var income_per_sec = ko.observable(0); income_per_sec.subscribe(function(value) { $("#income").html(value); });
It was easier to learn (much less magic to start with). And with computed observables (and one instance of extending the notify), it pretty much covers everything in an incremental.
Here is a computed example: var sum_obs = ko.computed(function() { return observable1()+observable2(); }); sum_obs.subscribe(function(value) { $("#sum-div").html(value); });
And that will update #sum-div whenever either observable1 or observable2 changes.
Everything else has been game-specific code, so I recommend KnockoutJS.
I'd start with Knockout first, which isn't a framework, per se, but what it does (2-way data binding), it does really well.
Angular also seems to have won the developer mindshare, IMO. At least I get contacted for Angular jobs all the time, not Backbone or Ember, which seemed to be more popular a year ago.
Hmm:
To answer your question, you could modify the do_get to be updated based on the earlier post, since you are going to be reloading the page after a successful post.
Now, you might already know this, but others who might come across this question might not. This is not a particularly good way to design a page. You would be better off posting to a new page that shows the expected results. Alternatively you could use some javascript libraries to just render the data actively on the page. I've tried knockout with a bit of success. http://knockoutjs.com/
The main positive for knockout is that it has some great tutorials on both the knockout side and the python (using flask) side. It was, if anything, easier to learn that the little javascript and jquery I know, and ridiculously easy to set up a page that dynamically hosts information. Using knockout the above problem could be solved by havign a template on the page that renders the data provided in the ajax response.
Cool, thanks. The shopping cart demo shows me it can do the kind of things I'm looking for. And the project aim and use-case sums up what I wrote above, in a fraction the number of words :-)
>AngularJS, Ember, Polymer and Backbone all seem interesting (albeit a little intimidating)...On the other hand, things like two-way data binding would still be very useful
Checkout Knockout, it has a MUCH lower learning curve and pretty much does one thing really well (two-way data binding). Go through their interactive tutorial. It's also a good intro into the MV* libs/frameworks, IMO.
It doesn't matter for Knockout. It has something called dependent observable/computed that will recomputed its value when one of its dependent has changed.
I did something similar using knockout.js for databinding and templating and enquire.js so that I can run a function to switch templates whenever a certain media query gets matched.
When my media query for small screen sizes got matched I would show my list of items using one specific template, when the media query for large screen sizes fired I'd just switch the knockout template used to visualize the list of items. This way it's perfectly possible to show your list of items as a table for desktop users and as an actual list for mobile users.
Start with Knockout, it's MVVM (model-view-viewmodel) and has a much lower learning curve.
Go through their interactive tutorial, it's quite nice at showing you what it's all about.
I don't know if this is something you're targeting but if your array is changing constantly then you can actually control the rate of limit to notify the subscriber.
myViewModel.myObservableArray.extend({ rateLimit: 50 });
Source at the bottom.
Knockout, which is missing from your list, is more mature, more popular, has better documentation, and has better cross-browser support than any of the others in your list. Seems that Facebook's React is the coolest one these days, though, and I might try that if I was starting a new project.
I've been playing with knockout.js for almost the same reasons as yourself, and it appears to be rather easy to use and powerful. I don't know if I'd put it above and beyond angular / backbone, but it has its place. The nice part being two way mapping of data <--> dom with automatic updating, it feels like magic.
I've been using Backbone.js in a pretty large project at work and it's pretty nice in some aspect, but there are other aspects that might be better with other frameworks. Also Backbone.js is not MVC.
Some other frameworks to consider:
Check out knockoutjs, it has a lot of the data binding capability you're talking about being able to support. Using the observables and observable arrays it wouldn't be too hard to rig something up that had an entire UI controlled via a JSON singleton.