Nobody is more excited about the most recent version of Google’s Chrome browser than JavaScript developers.

The latest version, Chrome 36, now includes a long awaited potential update to the JavaScript language. Called Object.observe(), it’s a low-level API (see our API explainer) that might solve one of the biggest problems in modern JavaScript development.

That problem: JavaScript developers have yet to find a satisfactory way to ensure that changes in a Web app’s underlying data—say, as the result of user input—are reflected properly in the browser display. (This basically reflects the fact that JavaScript developers usually separate an app’s data structures and its user interface into distinct program components. That keeps the coding simpler and cleaner, but also raises issues when the two components need to communicate.)

Various JavaScript frameworks offer workarounds that developers can use to get a WYSIWYG (What You See Is What You Get) display based on exactly what their app is doing. But these workarounds add more code that can slow the app down, alter the flow of its execution and potentially introduce new bugs.

Object.observe() would simplify the problem by creating a direct pipeline between an app’s data structures and its display. It can do this more easily because it’s an actual change baked into the structure of the JavaScript language itself, and not just a collection of bolted-on code.

Object.observe() is still unofficial; it’s so far only incorporated into Chrome, which means developers who use it can’t count on it working their apps working in others browsers such as Firefox or Apple’s Safari. And it’s not clear when—or even whether—other browser makers will jump on the Object.observe() bandwagon.

Still, the promise of Object.observe() is such that if it clears these hurdles, it could change the way JavaScript is coded forever.

What Is Object.observe()?

I asked Rafael Weinstein, a software engineer at Google who played a big role in Object.observe() and Chrome integration, to explain what it is and what it does.

While some developers have guessed that Object.observe() will replace or remove the need to use JavaScript development frameworks, Weinstein says that isn’t the case.

“Object.observe() is a low-level primitive,” he said. “It is an enabling technology which should make some existing JavaScript libraries and frameworks faster, more robust or both.”

In other words, Object.observe() is an additional function that will one day be built into JavaScript. Developers won’t work with it directly; instead, frameworks like Backbone, Angular, and Ember will add new libraries that rely on Object.observe() to keep app data and the app display in sync.

In an introduction to Object.observe at JSConf EU, Google developer Addy Osmani demonstrated how you can use Object.observe to view and edit code.

The main advance Object.observe() offers is a feature called two-way data binding. Translated from codespeak, that means it ensures that changes in a program’s underlying data are reflected in the browser display.

In order to view both the program’s data state and its display at the same time, JavaScript developers usually work inside a framework that includes a Model View Controller (MVC), in which the raw code appears in one window and the user display appears in another. However, current solutions for displaying both at once tend to bulk up a program with extra code devoted to data binding. The very act of observing the display changes how it is coded.

Amjad Masad, a developer at Facebook, has called two-way data binding the “holy grail of JavaScript MVC frameworks” because it sidesteps such workarounds.

“In the [Model View Controller] pattern, you have the model [i.e., underlying app data] that describes the problem you want to solve and then you have this view that renders it,” Masad told me. “It turns out that translating the model logic [i.e., the app’s data structures] to the user interface is a really hard problem to solve as well as the place in the code where most of the bugs occur.”

“When you have true data binding, it reflects automatically in the user interface without you putting in any ‘glue’ code in the middle,” Masad continued. “You simply describe your view and every time the model changes it reflects the view. This is why it’s desirable.”

It’s 2014. Where’s My Object.observe()?

Of course, nothing is an end-all be-all solution, not even an API that supposedly makes “the holy grail of JavaScript” possible. With Object.observe(), the hurdle that remains is that it’s still not an official part of JavaScript.

The Object.observe() proposal needs to be approved by TC39, the organization that oversees the development and maintenance of ECMAscript, a general scripting-language standard that encompasses JavaScript and several related languages. Currently, TC39 has approved Object.observe() as a draft, the second stage of the lengthy approval process.

See also: How To Build A WinJS App In 10 Easy Steps

TC39 members include developers from Google, Mozilla, Microsoft, and Apple. Weinstein, who submitted the Object.observe() proposal, said that since developers from these companies approved of adding it to ECMAscript, he’s optimistic that they’ll also want to add Object.observe functionality to their companies’ own browsers.

If Object.observe() becomes a standard feature across all major browsers, it’s more likely to be adopted as an official JavaScript component. Still, the longer Object.observe() development drags on, the greater the possibility that developers will cotton to some other solution to the data-binding problem.

For example, Weinstein is also at the head of a project called Polymer or observe-js, a library that uses Object.observe() if it’s available, and alternate methods if it isn’t. That way, developers can harness Object.observe() whenever possible, although they still have to be prepared in case their program runs somewhere it’s not supported.

Meanwhile. Facebook has come up with an alternative to Object.observe() called React, which developers can use now. React, however, isn’t an addition to the JavaScript language itself—just a framework adjustment that performs a similar function. (Object.observe() proponents argue that React is actually solving a related, but distinctly separate problem.)

Developers can try a number of solutions for fixing the data binding problem. But since the absence of data binding is itself a general problem for Javascript, you can see the attraction of adding something like Object.observe() to the language in order to resolve the issue in a relatively clean and universal fashion.

This Is Your Code On Object.observe()

JavaScript developers don’t usually code every part of their programs by hand. Instead, they use frameworks like Backbone, Angular, and Ember that incorporate libraries—chunks of code that handle frequently encountered programming hurdles.

For example, if you are a developer who builds a lot of contact forms for websites, you might have a library of software functions that shortcut the process of inserting a contact form in a website. So when the Object.observe() API is released, libraries will be built to make two-way data binding something developers can do as easily as inserting a library in their code.

In the absence of Object.observe(), JavaScript frameworks have each come up with a different ways of implementing two-way data binding.

The Angular framework uses something called “dirty checking.” Every time you add to your code, Angular checks to see what changed. It checks even if the view hasn’t changed at all. This continues once the app is deployed; every time the user inputs a change into the app while using it, the dirty checking code checks if it needs to refresh the display in response. This adds load time to every screen of your app.

The Ember framework uses something called “wrapper objects.” Basically, the developer adds a class to the object that serves as a “listener.” When the object changes, the “listener” triggers an event so the developer knows something changed. Since these classes are not native to JavaScript, they add loading time as well. Wrapper objects also increase developer labor, which inevitably leads to more possibility for bugs and errors.

Goodbye, Cruel Wrappers And Dirty Checking

Object.observe() make both of these workarounds obsolete. It allows plain JavaScript objects without wrappers to listen for changes. And only when the listener object notices a change does the view model itself alter, instead of indiscriminate dirty checking.

Igor Minar, lead developer on the AngularJS framework, said developers who use Angular won’t have to work with Object.observe directly.

“Object.observe() is a low level API, which is kind of awkward or inconvenient to use directly,” he told me.” That’s good because by providing such low level API the platform enables us to built on top the API and create higher layers with more opinions.” Object.observe() is already slated for addition as a feature in AngularJS 2.0.

Early versions of Object.observe() have already given Angular a performance boost. In a test, dirty checking took 40 milliseconds compared to Object.observe()’s 1 to 2 milliseconds. In other words, Angular became 20 to 40 times faster while using Object.observe.

Object.observe() has the potential to change the way JavaScript operates. But developers themselves won’t notice much of a difference in their workflow.

“Object.observe() is a low level feature that framework authors will use,” said Masad. “Developers using those frameworks won’t notice a different except for higher performance programs.”

Screenshot of Google engineer Addy Osmani introducing Object.observe() at JSConf EU