Live data from Hacker News

Why I moved from Angular to React

robinwieruch.de

91–100 of 107 posts

Re: Why I moved from Angular to React

#91
post #89

I've used ExtJS, Backbone, CanJS, Angular, Polymer and React commercially. To me, React is a more complex alternative to Google's Polymer framework. In React, a component is made up of code which has HTML inside it. In Polymer, a component is made up of HTML which has code inside it. They're actually the inverse of each other but the result is almost exactly the same - Both libraries allow you to build components whi…

> You can do cool stuff like allow a sub-component's style to change automatically as you move it from one parent component to another. I don't like this at all. I want all the styles to be encapsulated to the component only. It shouldn't matter what parent component it's in. Polymer's CSS automatically spills over into the child components.

> Polymer's CSS automatically spills over into the child components.

Hm? No, the opposite, the shadow DOM provides CSS encapsulation.

Re: Why I moved from Angular to React

#92
post #91
post #89

Earlier quoted context omitted.

> You can do cool stuff like allow a sub-component's style to change automatically as you move it from one parent component to another. I don't like this at all. I want all the styles to be encapsulated to the component only. It shouldn't matter what parent component it's in. Polymer's CSS automatically spills over into the child components.

> Polymer's CSS automatically spills over into the child components. Hm? No, the opposite, the shadow DOM provides CSS encapsulation.

Ok, sorry. I misunderstood it then. So what does this mean?

"potentially including sub-components but not parent components"

Re: Why I moved from Angular to React

#93

Surprised that a blog post is published this year that is about moving from AngularJS (v1) to React. That's not really that big of a shock, lots of devs are doing that. A better comparison is Angular (v2+) vs. React, and it is really a good fight that boils down to whether you want a framework, or you want the freedom to build your own from specific parts.

Which one do you suggest would just be the parts?

Re: Why I moved from Angular to React

#94
post #83
post #37

Earlier quoted context omitted.

As mentionned already, and as Pete Hunt famously talked about in "Rethinking Best Practices" (you can find it on youtube), you want to separate -concerns-, not technologies. Often there is a 1:1 between those things, but not in modern web development. So we've seen a push toward components that mix technologies, but separate concerns. And it's been great.

This is just rhetoric. The notion of separation between information, presentation and behavior couldn't be any more fundamental. But instead of developing this idea any further most web developers had traditionally settled for something "easy" and complicated (i.e. JQuery that dictates all of the three things I mentioned). In the long run, the SPA craze will backfire, big time. Rect components are not semantic and no…

I'm with you on 'declarative' but I'm always sceptical about 'semantic'. Its meaning is vague, its benefits somewhat ethereal and its actual existence in the real world a matter of rumour and speculation.

If you can pin down your definition then I'd be able to provide a more concrete opinion.

> The notion of separation between information, presentation and behavior couldn't be any more fundamental.

Fundamental to whom? Outside of web development this separation was never fundamental - see the post above regarding "separation of concerns" - which is a much better candidate for a "fundamental principle"

Re: Why I moved from Angular to React

#95
post #37
post #27

React comes with its own syntax to build components called JSX. In JSX you can mix up HTML and JavaScript. Additionally people often use inline styles in their elements. It is like adding CSS into the mix. This really scares me. We spent a lot of effort removing inline styling from HTML with CSS, and yet it still creeps into our HTML. We also have created a lot of "template" languages (e.g. PHP, Python, ERB, etc.) mi…

As mentionned already, and as Pete Hunt famously talked about in "Rethinking Best Practices" (you can find it on youtube), you want to separate -concerns-, not technologies. Often there is a 1:1 between those things, but not in modern web development. So we've seen a push toward components that mix technologies, but separate concerns. And it's been great.

Why not separate concerns AND technologies at the same time. Concerns for the logical organisation of the code and technologies for easier editing of the same code.

Re: Why I moved from Angular to React

#96
post #92
post #91

Earlier quoted context omitted.

> Polymer's CSS automatically spills over into the child components. Hm? No, the opposite, the shadow DOM provides CSS encapsulation.

Ok, sorry. I misunderstood it then. So what does this mean? "potentially including sub-components but not parent components"

You CAN optionally have styles from a parent component affect child components but you can also restrict the styles to the host component only (excluding children) if that's what you want.

I find that often though, I like the host component to affect the style of child components - For example, let's say we have 2 container components which hold a list of items; one container component shows its items as rows and the other component shows items as thumbnails (with a picture). In this case we want the parent container component to affect the style of the child item (thumbnail vs row). If we were to drag an item from one container and drop it into another, we would want the style (thumbnail vs row) of the new parent container to take effect on the child (without having to imperatively update styles in the child).

The danger in traditional (non-WebComponents) CSS is not the cascading aspect of it; it's the fact that it's global. If you localize CSS to components such that it only cascades downwards in the DOM hierarchy, then it solves all your problems.

Also, because of the CSS specificity rule, style properties defined in the child will overwrite those from the parent, so the child always gets the last say about how it looks - With this approach, the child can effectively decide which CSS properties its parent is not allowed to modify.

Re: Why I moved from Angular to React

#97

Earlier quoted context omitted.

How is React running natively in React Native? The most basic things are reimplemented (quite badly) in JS, such as controller navigation (for the lack of a better term), buttons, gestures, animations. Most of them run on the JS stack, which is run on a JavaScriptCore VM instance, the same VM running when using a web view. How is any of that native? For me, "native" means using only OS-native components for navigatio…

The choice of words was poor, but the point of the original poster, I think, were clear. React-native provides react with primitives that are native (such as View, Button etc...). Navigation is also native (as in the transitions are native). Until angular or vue can run withou the dom (which is the #1 reason for performance issues in wwb apps), they cannot compete with react.

Transitions are not native. They are simulated to appear as if native from JS.

Re: Why I moved from Angular to React

#98
post #92

Earlier quoted context omitted.

Ok, sorry. I misunderstood it then. So what does this mean? "potentially including sub-components but not parent components"

You CAN optionally have styles from a parent component affect child components but you can also restrict the styles to the host component only (excluding children) if that's what you want. I find that often though, I like the host component to affect the style of child components - For example, let's say we have 2 container components which hold a list of items; one container component shows its items as rows and the…

Ok, that's cool. I might try Polymer out but I think I'll stick with React due to the community aspect you mentioned.

Re: Why I moved from Angular to React

#99

React has this intended/unintended side effect of teaching functional programming concepts without making it obvious. For me, after finding out the core concepts of React (views are pure functions, functional composition etc.) are actually functional programming applied tastefully to rendering, I finally realized the elegance of functional programming, and since than I've been merging these concepts into my programmi…

I think that's a big win. With React, you can see the use for functional concepts without having to switch to a functional programming language, or completely divest your codebase of 'friendly' object oriented techniques like class structure and subclassing. Similarly, I'd give a shout to MobX for showing me how observables can be used in practice. For the longest time I'd wanted to learn it, but I'd choke on the syn…

MobX makes React simple because it's JavaScript. If you've write React with ClojureScript, you will find out that ClojureScript simplified React too. And people may also say ClojureScript is the magic piece that make React great.

Re: Why I moved from Angular to React

#100

Earlier quoted context omitted.

I think that's a big win. With React, you can see the use for functional concepts without having to switch to a functional programming language, or completely divest your codebase of 'friendly' object oriented techniques like class structure and subclassing. Similarly, I'd give a shout to MobX for showing me how observables can be used in practice. For the longest time I'd wanted to learn it, but I'd choke on the syn…

MobX makes React simple because it's JavaScript. If you've write React with ClojureScript, you will find out that ClojureScript simplified React too. And people may also say ClojureScript is the magic piece that make React great.

How would ClojureScript help here?
Post reply on HN