Still not sold? See if React’s Pete Hunt can sway you.
The Solution? How About Components?
So I’m React Fanboy?
If two things go together logically, then it sure would be nice if they go together physically as well.
1. I’m referring solely to the separation of HTML & JS. The Wikipedia article lumps progressive enhancement under the unobtrusive JS banner. Progressive enhancement is an orthogonal concern in my mind and certainly continues to be a useful pattern.
Good post Corey.
Also of note, this isn’t the first time that “outside concerns” were moved into imperative code. Declarative stored procs have been assimilated into C# without any consternation. The reality is, you can do it however pleases you, and that’s what *really* matters.
I don’t see a problem with the current usage of MVVM vis a vis Knockout et al. You can see which elements are affected in the html due to the data-bind attribute without ever looking at the js file. There’s very little you need to do on a page that can’t be handled using this pattern.
Thanks for the comment. I agree that the KO data-binding pattern is effective and works well. I’ve just found that having the model and markup in the same file is preferable for reasons outlined above.
But doesn’t this approach break down when working with designers?
The markup is now buried in some code which is hard for designers to read. There’s also a disconnect between css classes used and where they are declared.
With markup and code in separate files, I can open them in two windows and position them side by side. I can’t do that when they are in the same file.
I use knockout to update my html and take care to only bind to properties. Anything resembling logic is moved behind a computed property.
There will always be something which need to be in sync between markup and code. The easiest fix is to keep both files next to each other.
There are many good things in React, but inlining html in code isn’t one of them.
Since JSX looks almost identical to HTML, I don’t see a big problem. While you’re sharing a common concern, I’ve already read accounts of devs working with designers who had no issues training the designers on the minor differences. In KO and Angular designers have to understand proprietary tags such as ng-repeat and data-repeat, etc. In React, they have to understand class is now className, and for is HtmlFor. It’s a pretty shallow learning curve on either side.
How could “having the model and markup in the same file be preferable”?
Why reinvent and break the already existing separation of concerns given by HTML and JS?
What about reusability and extensibility?
What if I want to reuse a view-model for a different view or extend an existing view-model and use it for a different view?
With React, separation of concerns is provided at the component level. Each component is autonomous and provides a clear interface. I find component-based decomposition more useful because the separate HTML and JS files in other frameworks must move in lockstep anyway.
Regarding reuse, well designed components are of course reusable. And you could enjoy the same “viewmodel” or “view” reuse via React if desired.
There are two advantages to this.
1) It automatically makes the site mostly accessible (disclaimer – most, not all ). Reducing extra aria, reducing extra accessible data information and updates, simplifying the architecture.
React can indeed do so by being rendered first on the server (Isomorphically/Universally). When done so, no accessibility is sacrificed. That said, the choice to support people running without JS is up to the business. Utilizing progressive enhancement techniques is far from free. For many applications that sit behind a login, supporting those with JS off doesn’t pay off enough to justify the cost. And despite your claim, separating HTML doesn’t speed the dev process. Quite the opposite – One must carefully keep the HTML and JS in sync without a strongly typed interface which leads to higher mental load and cryptic run-time failures. In a new world that is embracing component-based decomposition, splitting on technologies for work sharing purposes no longer makes sense.
Comments are closed.