Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

I get that but disagree with it. I don't see it as an arbitrary separation but a necessary one based on separating the view (which a team of designers can freely modify without worrying about breaking anything or even touching the logic) from any logic that can handle events.

Honestly I try to use messaging where possible for these types of things. The last app I wrote should, theoretically, be able to be moved from an HTML app to a node-qt app only by swapping the views.

But like I said I haven't had a ton of experience with either so I can't make any good, factual points here only my personal preferences and anecdotes.

View on HN

> separating the view (which a team of designers can freely modify without worrying about breaking anything or even touching the logic) from any logic that can handle events

Where does the designer's job stop ? Does he not handle animation ? Should he be in charge of CSS too, because that's how you do basic animations ? Why shouldn't he be in charge of slightly heavier animations, just because they're in javascript ?

The point of the authors (which I agree with) is that the whole notion of "view == template" is wrong, and thus "view == html+css files" is wrong. A view is the thing the user interacts with: a button, a list of items, a search bar. All these components should be handled as a whole, and should be handled independently from one another. If a component doesn't need any javascript for it's logic, fine; if another component needs some javascript for whatever reason it's nonsensical to separate this javascript. A design doesn't always stop purely at static appearance.

The fundamental unit is the object you're working on, not the technology you're using.

If the rule is a) designers only touch .html/.hbs files and b) only developers touch the view/controller .js files, then if either of them change a property name from `{{displayName}}` to `{{display_name}}`, the whole thing breaks, which is the coupling React is trying to avoid by keeping these similar concerns within the same technology/file (JavaScript).

"(which a team of designers can freely modify without worrying about breaking anything or even touching the logic)"

wut

edit: JSX accomplishes this goal handily, no other tech i have ever used comes anywhere close to JSX, and I have used nearly all of them. (I'm the engineer who manages the designer and integrates his changes. Interactions with the designer are like, "Go to line 37 of XJZ.js and make it look like foo." In JSX, there usually isn't any integration to do as he can commit directly. Which is why JSX rocks.)

Never worked with web designers? Typically folks who are great with design and doing some styling and markup? We have some really awesome folks with the current company I'm with so they frequently work with the developers to make their shit sexy.

Edit: to address your edit that seems overly complicated to me. Most of the web designers (or designers in general) don't know a lot of JavaScript; asking them to make structural changes inside of JavaScript worries me a little. I'd much rather them change the view in its natural state: html and css. JSX isn't that.

so instead of pointing your designers to a .html file, you point them to a .jsx file? not seeing the issue.

also:

    var MyComponent = Reate.createClass({
      render: function () {
        return require('./template-designers-are-not-scared-to-touch').apply(this);
      }
    });

but this is a silly separation

Reply on news.ycombinator.com