Two-Way Data Binding
n12v.com
n12v.com
This is actually a feature of React: your UI is guaranteed to always be in sync with your underlying data!
...
It sounds like you want to be able to show either an exact °C temperature or an exact °F temperature, so the best approach here seems to be to store that as well. Otherwise, you're feigning more precision than you actually have.
The way I thought about it is that a temperature conversion model entity needs 4 API points (get as °C, get as °F, set as °C, set as °F), and you want the canonical precision to be bound to the latest modified unit of temperature.
The "mathematically correct" approach would get pretty complicated with a fraction library and value objects, but given that the output of the conversion cannot always be expressed as a decimal on the UI in the first place, and that the weight of the "correct" solution far outweights adding a second storage variable, we can make an engineering decision to simplify the implementation while staying correct enough for the purposes of the example. In fact, the vanilla JS implicitly does the exact same thing by storing the canonical precision in the last modified field's `value` attribute.
Typically, you'd want to store the result of a computation when setting anyways, since re-computing them on every read can be expensive.
In code, this simply means that you store the latest modified value as-is, and store the imprecise computed value for the other unit of temperature:
var Temperature = function() {
this.setCelsius = function(c) {
this.celsius = c
this.fahrenheit = 9/5 * c + 32
}
this.setFahrenheit = function(f) {
this.fahrenheit = f
this.celsius = 5/9 * (f - 32)
}
}
var t = new Temperature
t.setFahrenheit(2) //we want 2°F to mean 2°F, not 1.999...
You are not required to use models in Backbone, especially for such a trivial example. You aren't using an equivalent of models in the vanilla JS example. You aren't required to listen to change events to render anything.
Here is a simple Backbone view doing an equivalent to what the vanilla JS example is doing:
Of course the Backbone example looks over the top. And compared to all of them the vanilla JS looks like an example of beautiful simplicity. But try making a full webapp using vanilla JS and you'll find things get very messy, very fast.
Never mind the fact that the entire point of frameworks like React is that they're performant with a lot of DOM changes being made frequently. Making a demo that shows it altering one text box isn't really very useful.
We have a similar thing here: The issue isn't whether you can do X with/without framework Y. It's whether framework X is more cost effective vs. framework Z (or no framework): Does it require less/more boilerplate? Is it less/more error-prone? Does it mean that more/less experience is needed to do the right thing? Does it mean that testing becomes harder/easier? &c.
Which is to say that I definitely recommend that everyone at some point develop their own all-purpose framework, because it's a great learning experience, but if they're doing production work they should stick to one of the existing ones, even if it's just so other developers will have an easier time understanding the codebase.
I know, nobody does that cause it's hard. The frameworks certainly don't help.
You can write great software without MVC, or frameworks, or OOP. Frameworks are often crutches for people's anemic design skills. They're not nearly as important as everyone thinks. You can easily coordinate multiple people working by, you know, sketching out an architecture amenable to he division of labor.
Anyway, my point is that if you're working on a non-trivial solution in a problem domain that other people with good design skills have built frameworks for (like web dev, the most oversolved domain in software, aside from text editing), it doesn't make economic sense to roll your own. Even if you have the rare trait of good design, the productivity benefit for yourself by having a more closely adapted framework is washed away by the cost of building it and having to bring other people up to speed on it. I've had the experience of lots of home-grown framework code, and rolled my own quite a few times, and the longer i've had to observe other developers working on that code the more convinced i've become of NIH being a programming anti-pattern. It can make sense to roll your own, but for the majority of web dev programming it doesn't. There may be categories of software dev where the statement inverts though, i'm not going to generalize too far.
What i however also think is that many of today's frameworks are overengineered and force you to write too much code to solve a problem. They suffer from tdd-induced design damage, as dhh would describe it (the recent discussion between fowler, beck and dhh was enlightening). Many frameworks have optimized for secondary goals like orthogonality or compliance to design patterns instead of primary goals like fitness for purpose, speed of development, maintainability, and usability of the resulting product. However, i'm of the opinion that even given all that, for general web dev and for most people, it's better to use one of the common ones than to roll their own. They'll build a more maintainable solution in less time.
Good point. I could use better wording. The message that I was trying to convey was:
You can use Backbone models but please don’t do it like this. Backbone doesn’t do DOM diffing like React; you’ll shoot yourself in a foot.
I may be biased since I wrote it and I’m using Vue.js everyday, but I think it is really comprehensive compared to others.
Edit: if you want to know more about Vue.js [2], especially how the data binding works (hint: no dirty checking, no ES6), the FAQ [3] is a good read.
IMHO, Vue is a very interesting project and I think this particular article is a very good fit to show its strengths, but I think my comment (at the bottom of the article) still applies to it. For example, it's not particularly obvious how to change a binding to use the blur or the change event, without scouring the documentation. Or that `v-model` and `computed` and `$get` and `$set` are the names of the things that, in conjunction, do what you want in this particular case.
In that sense, the Mithril code is more straightforward to write and to control, because the abstractions that it provides complement - rather than replace - a naive implementer's workflow. This is the aspect that I believe eddyystop is talking about.
In particular, I like that the JS code is free from cruft as in the other examples there. I also like that the HTML stands on its own which makes the UI design process easier.
Prior to this I had been considering RiotJS[1].
[1] https://muut.com/blog/technology/riotjs-the-1kb-mvp-framewor...
But what I have emphasised on is that vanilla JS, with zero dependencies, is actually shorter code than any other solution. And works just as well. Not that you'd want to develop all applications without the help from libs/frameworks, but sometimes that abstraction simply adds unnecessary complexity.
Or that the web is a flawed platform and should be avoided?
IMO it's close to a data-binding library, rather than a full-fledged framework, it works well, is simple, and relatively performant.
I found that I had absolutely no need for jQuery, etc. Just do all UI stuff with CSS+HTML and use Knockout's data binding for binding it to data and logic.
Knockout is a little rough and has some weird edge-case gotchas and syntactic inconsistencies but I like it. Might look at Mithril in the future.
Still no JS UI framework nirvana as near as I can see.
If you're new to the framework, note that `ReactLink` is not needed for most applications and should be used cautiously.Then I started doing CocoaTouch for a project with a friend. I can't view the source, and the tools suck ass (xcode, obj-c) but compared to Javascript and especially the frameworks for web apps, it's wonderful!
The JS frameworks, all of them, make things a hundred times more complicated than they need to be. If web programming was like CocoaTouch, but with a dynamic language, it would be great. /rant
If you love cocoa so much you should checkout: http://www.cappuccino-project.org/
I remember when Swing was big. Everyone was gushing about it despite obvious flaws: non-native UI, poor startup time, horrible accessibility, and ridiculous memory consumption. Industry loves the idea of one platform-to-rule-them-all, no matter how far behind the uber-platform is. It would rather dump endless amounts of money and time into a patchwork of hacks than admit that it was wrong.
We're way past due for a VM for webapps. I don't see why the VM couldn't be added as a dual to the current HTML/JS/CSS model. URIs beginning with app:// would use the new VM model. There's a shocking amount of defeatism, both by developers and institutions surrounding the tooling of webapps.
I don't know what the answer is, and I agree with you that a huge part of the problem is that trying to build web applications on a platform intended for web documents doesn't work very well. But it seems to work better than everything else we've tried.
I'll be the first to say: creating views in those systems is usually not as easy as HTML. But the coherence of the tooling makes up for it quickly.
It appears the development ecosystem is optimizing itself around what lets you throw shit up as fast as possible, regardless of how coherent or painful it is to modify in the future. Time-to-market has always been a concern, but the notion of Internet-time has only accelerated things.
This also explains why R&D has taken a backseat many times; we often confuse it with new products (that use the same tech).