12 ms·

Why I moved from Angular to React

189 points by rwieruch 10y ago

aviraldg 10y ago
For me, the conceptual simplicity of React (and associated projects) makes it very easy to reason about code written with it. If you've worked on a larger Angular project, you know this is a huge win - keeping things simple there requires a disciplined developer with a good understanding of Angular (a rare combination.)
hakanderyal 10y ago
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 programming methodologies.
- michaelchisari 10y ago
  You should give Elm a look, then.
  - pka 10y ago
    And after that, PureScript :)
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
  - hakanderyal 10y ago
    I'm really interested in Elm, it's on my 'things to explore' list. But I've already built a big 'component' library for my designs and style in React, and it's hard to justify a switch to anything else for a long time. And sadly that's the biggest problem the upcoming languages/frameworks face.
    - noir_lord 10y ago
      Yup, I still use knockout because I have components for nearly everything I do.
      - disease 10y ago
        Do you mix React and Knockout components by any chance? We are looking at moving from Knockout to React and I was wondering how painful this would be. My guess would be that if you are doing all or most of your KO stuff with components, then the switch shouldn't be too bad.
        taude 10y ago
        I've done some mixing of Knockout and React. We had a custom datagrid that was taking a long time to bind up all the data with templates. I think it was made almost 8x faster for rendering moving it to a React component. This was a POC project done probably 18 months ago.
    - michaelchisari 10y ago
      Nothing wrong with that. I'm on a greenfield project with no particular deadline, so I chose Rust + Elm, but if I had to build rapidly, or had already committed a bunch of code in another framework, I'd definitely stick with that.
- true_religion 10y ago
  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 syntax and the generality of common libraries. Showing how MobX worked to simplify React code, gave an instant sense of success and things clicked afterwards.
  - jiyinyiyong 10y ago
    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.
    - true_religion 10y ago
      How would ClojureScript help here?
      - jiyinyiyong 10y ago
        I'm saying MobX is not the final answer for React. Behind React is the theory of uni-directional data flow. Observable in MobX looks nice and it fixes uni-directional data flow in JavaScript syntax of assignments. Seeing from ClojureScript and other languages that implemented persistent data structure by default, MobX is just a tricky solution designed for JavaScript. And ClojureScript handle uni-directional data flow well too with persistent data and atom type.
        true_religion 10y ago
        Ah I see. I wasn't saying it is the final answer. It's just a 'good thing' because without it I wouldn't have learned observables to the depth that I did. It's a start... because it brings the concept to Javascript, a language that I'm already familiar with and have a build chain for. If one is going to switch languages, then you can consider the whole sweep of compile-to-JS languages. Elm is pretty nice in that scenario, and pairs well with my use of Elixir on the backend.
dhbradshaw 10y ago
All these discussions miss the point to me: React can be run natively on Android and iOS. Can Angular? Vue? Elm? It seems like there can't be any real competition when starting a large class of new projects until the answer is "yes." So I'm asking: what are the best real alternatives that work natively on mobile?
- _some_guy 10y ago
  Check out NativeScript, you can use Angular 2 to build native mobile apps.
  - nadermx 10y ago
    I'm still torn, most everyone I have talked too that did a non native app said they would never do it again and would rather do native.
    - dbbk 10y ago
      NativeScript does make native apps. It's in the name.
      - LeoNatan25 10y ago
        Agree that NativeScript is the most "native" of the JS cross platform tools, since it can use actual native concepts, such as controllers, views, gesture recognizers, etc, whereas things like RN throw the "native" word everywhere, but actually implement everything internally in JS. A small example - a tap gesture in RN is actually implemented using `touchesBegan:` API, which routes input to JS over RN bridge, JS performs the tap logic. Doesn't sound terrible, but consider that the RN bridge is async, so the user experiences a floaty behavior, and if that single JS thread is busy with some business logic, you are dead. Same for animations and interactions. Navigation is a joke, with current and other implementations being JS replicas of the real thing, and the native NavigatorIOS, the one to use actual native iOS concepts, being deprecated. NativeScript also has a novel idea how to implement multithreading in JS, which is commendable.
matmo 10y ago
Only some of these are percieved advantages over Angular. Alot of them are advantages over AngularJS, meaning AngularJS 1.x I'm obviously biased, but using Angular (2+) with typescript and ngrx (observable based redux, essentialy) has been really nice to develop with.
- jordic 10y ago
  Till you try to build a web c omponent or embed an agular2 app in an existent DOM (haha)
  - matmo 10y ago
    How are you going to embed an app in another app/DOM without using an iframe, and how is creating that iframe going to be any harder to accomplish depending on the technologies used inside of it? I'm not sure what you mean about components...Angular is component based. Are you referring to native web components?
    - jordic 10y ago
      Take a rich component from your angular UI/lib and export it as a web element. (React/preact/vue/polymer) can! Manage an stream of html comming from a backend CMS. An upgrade their DOM.
      - matmo 10y ago
        I see. Yeah, Angular probably doesn't target environments where it isn't the main/driving DOM/context.
        jordic 10y ago
        That's one of the problems.. it only covers an slice of the front-end space. And also there is some kind of lock-in.. you can't reuse your components for something else.
sweetheart 10y ago
I find it hard to switch away from React to another similar library/framework simply due to the community that surrounds the "React ecosystem". Having worked on applications using Angular and Vue, I've just had such an easier time solving my problems when using React because there just seem to be more man-hours sunk into developing best practices, which naturally leads to more mature libraries, frameworks, solutions, etc. There are many things that the "React ecosystem" has taught me that I can apply to any future application I build regardless of the stack, but many of my problems were solved in little time because the SO answer to my questions also used React, or the answer came in the form of a React component I could plug in and not worry about. Maybe when Vue's community is as thoroughly developed I'll try that out again. Right now it's hard to find a reason to switch.
josinalvo 10y ago
Just a bug report: In the end of the article Mr. Rwieruch offers a free ebook to those that join his mailing list, unfortunately that does not happen. You are instead sent (after confirming your email) to a site that lists the 'minimum price' of the book as free, gives you a price slider that cannot go bellow 14.99 (and the "additional information icon" when hovered, shows a minimum price of 14.99, contradicting the page's own previous claim) A resolution that allows other users to aquire the free ebook is preferred, but removing the offer of a free ebook would also solve the problem.
- rwieruch 10y ago
  Hi josinalvo, can you try the page again? As a student, the eBook should be pay what you want. You are the first person who reports the issue unfortunately. Sorry for the inconveniences.
  - josinalvo 10y ago
    No problem. Thanks for the prompt response. I had tried as a student before. Just to make sure, I tried again. Slider wont come to less than 14.99. See screenshot: http://5cm.ru/view/i7/AwQ7.png http://5cm.ru/view/i7/AwQ7.png Note that it says free on the page, and minimum=14.99 on the dialog. Also note that student is selected
Garbage 10y ago
My experience with Angular has been very different. I never felt pain working with Angular. Most of the issues I saw, boiled down to bad code. And I think those issues would still be there irrespective of framework used. I also don't get why two way binding is difficult to reason about. Can somebody please give me an example?
- jordic 10y ago
  Because your state is spread everywhere... I used a lot angularjs before, and it's not bad, but I must admit that the jsx abstraction is so powerful.
wmccullough 10y ago
In other news: Why I moved from table salt to sea salt.
- grzm 10y ago
  If you feel the topic is inappropriate for HN, flag and move on. Snarky, dismissive comments like this don't add constructively to any discussion.
  - solidr53 10y ago
    It's pretty funny tho, I thought immediately of Top Gear
gvb 10y ago
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 <program language dejour> "template" languages (e.g. PHP, Python, ERB, etc.) mixed in with HTML, which also tends to end badly (logic buried in HTML that is hard to find and hard to reason about). How does React solve the "everything mixed into HTML" problem? Are we going down the same path that ended badly last time?
- zinckiwi 10y ago
  It switches the axis of concern from separating out the different classes of code (HTML, JS, CSS) to separating out the functional goals of your code (Component A does this specific thing, Component B does that specific thing). Realistically, the triad of front end technologies are tightly coupled, regardless of whether they're in the same file. If you can keep your components nicely bounded, then it's far easier to have them be self-contained.
- jordic 10y ago
  Take the CSS for an small button and add all the variations you need. And after some time someone not so skilled like you arrives and adds a padding to the first button. That on scale it's not easy solvable. And that's the reason why we are looking for other approaches to isolate/share the main functionality.
- ariabuckles 10y ago
  This sounded scary to me at first, but in practice I've found it to be the opposite. Separating css, html, and js makes sense when you're writing a document, and the content is the html and the css is strictly formatting. It makes less sense when you're writing an app, and the styling of the html is an integral part of what is being created. The javascript works the same way; it's often integral to what's being rendered, not just patchwork adding small amounts of functionality to an existing document. But probably most importantly is that react gives you a different way of separating concerns: it's very easy to put different chunks of the UI into different components/files, so your app is divided by functionality, instead of divided by technology. Keeping the html (and sometimes css) with the js that uses it helps increase the cohesion of small units in your UI that intimately work with each other, while separating those from other js/html/css for other units.
trumbitta2 10y ago
How many of you developers who use React and say that JSX is the second coming of Jesus, are also able to produce a semantically coherent HTML document with JSX? It seems to me that React + JSX are perfect for "divitists" and devs who use a h3 because its font-size has the desired value. I'm not being sarcastic, I genuinely can't understand why a good web developer who cares about the meaning of a HTML document should like JSX.
- tomelders 10y ago
  Well there's nothing stopping you using the right element for the job. But I would argue that the semantics of HTML, whilst useful in a publication paradigm, don't translate as easily to a web application, which is where React shines. I'd also argue that React is not a good fit for something like a blog, or a news site.
  - lllr_finger 10y ago
    This is a great point, and a sword I fell on at my previous employer. React is great for stateful web apps - a blog or a news site have some state, but aren't really that state heavy. Especially when you have a news site getting millions of views, you simply can't afford 1 second on page load to download, parse, and eval React and your data model for little gain. I've seen devs that are so infatuated with React and "isomorphism" that they will use it as a hammer for every screw they come across.
- lllr_finger 10y ago
  I wouldn't argue that it's the second coming of Jesus, but it's been pleasant to work in. React creates HTML from JavaScript, and JSX is a convenient, intuitive, and familiar way to express your code. I've found that React generates trustworthy HTML, letting me focus on business logic and the interesting parts of development. I've never come across a scenario where React threatened the coherency of my code (other than the data attributes that are now optional, thankfully).
- BigJono 10y ago
  I must be completely missing your point. React supports the vast majority of html elements. There's nothing I can think of about React that would encourage someone to misuse html, you're using the exact same tags you'd be using to create a vanilla site. The only difference is that you're declaratively defining how they change based on state. A good html developer will still use best practices when using React, a bad one won't. What's the difference?
pinnbert 10y ago
I'm sure many people moved from Angular to React and didn't feel the need to be social about it.
vinhboy 10y ago
Biggest reason: A lot more react jobs than angular jobs.
- keyle 10y ago
  Really? Where? Here in Australia it's all AngularJS (they're all jobs converting 1.x to 2.0) and sadness :(
rch 10y ago
I'm glad this conversation continues to evolve, particularly now that Angular(2?) has stabilized. Practically speaking though, I'm evaluating high-level frameworks like Blueprint, Clarity, and Element, vs. the prospect of becoming a bespoke framework provider myself (probably not). If I'm starting off with a respectable set of components, then I can adapt to the lower level libraries as necessary.
- acemarke 10y ago
  I'm pretty happy with Semantic-UI-React myself ( http://react.semantic-ui.com/ http://react.semantic-ui.com/ ). Blueprint does look pretty well designed, too.
jondubois 10y ago
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 which contain other components and both provide clean encapsulation. One of the reasons why I have a slight preference for PolymerJS is that it's much simpler and works with existing HTML concepts (they didn't need to invent a new debugging panel, a new DOM model, a new approach to CSS styling or an advanced state management architecture like Redux to make it work) - Instead, they leveraged existing web technologies. For example, Polymer provides really nice CSS style encapsulation. In PolymerJS, the <style> tag only affects the component in which it's declared (potentially including sub-components but not parent components). It makes CSS really easy to use/maintain without actually reinventing it. 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. You don't need any special module or library or special styling logic; just a <style> tag declared at the appropriate level in your component tree/hierarchy is all you need. That said, the React community is massive and because of this, there are tons of modules and tools around it so it's hard to beat now - It seems that pretty much every problem that React has introduced has since been fixed.
- acemarke 10y ago
  On the flip side, React's composability and generic component rendering concept allows it to be reused across many non-HTML platforms, including React Native, ReactVR, and more (per this list of React renderers: http://iamdustan.com/react-renderers/ http://iamdustan.com/react-renderers/ ). Also, fwiw, Facebook didn't invent Redux, Dan Abramov and Andrew Clark did _before_ they joined the React team :)
  - jondubois 10y ago
    There is nothing inherent to React which makes it easier to render on native platforms. This could easily be achieved with Polymer too - It's just that the Polymer community is much smaller so they're behind in that respect.
Shooogur 10y ago
Yea but the real question is....have you used aurelia?
LocalPCGuy 10y ago
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.
- iso-8859-1 10y ago
  Which one do you suggest would just be the parts?
  - xchaotic 10y ago
    React is built out of components
andrew_wc_brown 10y ago
Mithril is the best.
tmpxxx 10y ago
I think some people just don't get React. The beautiful thing about it is that it's really simple. Yes you create components but it's not just about components. The idea that you can treat your app ass a function and just feed it one global state is what makes it so powerfull imo. That being said there are a lot of paradoxes with react. For example it was created with functional ideas in mind and the functional comunity loves it, but at the same time i have the impression that the facebook deeloppers building it just didn't got it for a long time, and its still sinking in. Just looking at how there are classes for everything and all. It looked mor OO at the begining. And the whole flux, one would think they dont't understand the power of simplicity completly. Then there is the problem of finding the correct patterns to work with it. A lot of times you have OO people that start writing js software and when you look at the code they produce you feel like crying. Then they blame react because they just don't know how to think different.
0x54MUR41 10y ago
I have experience building a mobile app using Ionic framework. Ionic uses Angular for its view library. In my opinion, one thing that I dislike about Angular is documentation. I think Angular has lack of documentation. It has short explanation and no examples/use case for that function. I don't know if the documentation has changed since then because I built that app in 2015. Now, when reading Hacker News, a lot of people post about React. I have never learnt before. Maybe, I am late to the party. I must dig posts about React to know its use cases.
rstormsf 10y ago
now you need to move from react to vue.js

189 points by rwieruch 10y ago

For me, the conceptual simplicity of React (and associated projects) makes it very easy to reason about code written with it. If you've worked on a larger Angular project, you know this is a huge win - keeping things simple there requires a disciplined developer with a good understanding of Angular (a rare combination.)

hakanderyal 10y ago

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 programming methodologies.

michaelchisari 10y ago
You should give Elm a look, then.
- pka 10y ago
  And after that, PureScript :)
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
- hakanderyal 10y ago
  I'm really interested in Elm, it's on my 'things to explore' list. But I've already built a big 'component' library for my designs and style in React, and it's hard to justify a switch to anything else for a long time. And sadly that's the biggest problem the upcoming languages/frameworks face.
  - noir_lord 10y ago
    Yup, I still use knockout because I have components for nearly everything I do.
    - disease 10y ago
      Do you mix React and Knockout components by any chance? We are looking at moving from Knockout to React and I was wondering how painful this would be. My guess would be that if you are doing all or most of your KO stuff with components, then the switch shouldn't be too bad.
      - taude 10y ago
        I've done some mixing of Knockout and React. We had a custom datagrid that was taking a long time to bind up all the data with templates. I think it was made almost 8x faster for rendering moving it to a React component. This was a POC project done probably 18 months ago.
  - michaelchisari 10y ago
    Nothing wrong with that. I'm on a greenfield project with no particular deadline, so I chose Rust + Elm, but if I had to build rapidly, or had already committed a bunch of code in another framework, I'd definitely stick with that.
true_religion 10y ago
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 syntax and the generality of common libraries. Showing how MobX worked to simplify React code, gave an instant sense of success and things clicked afterwards.
- jiyinyiyong 10y ago
  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.
  - true_religion 10y ago
    How would ClojureScript help here?
    - jiyinyiyong 10y ago
      I'm saying MobX is not the final answer for React. Behind React is the theory of uni-directional data flow. Observable in MobX looks nice and it fixes uni-directional data flow in JavaScript syntax of assignments. Seeing from ClojureScript and other languages that implemented persistent data structure by default, MobX is just a tricky solution designed for JavaScript. And ClojureScript handle uni-directional data flow well too with persistent data and atom type.
      - true_religion 10y ago
        Ah I see. I wasn't saying it is the final answer. It's just a 'good thing' because without it I wouldn't have learned observables to the depth that I did. It's a start... because it brings the concept to Javascript, a language that I'm already familiar with and have a build chain for. If one is going to switch languages, then you can consider the whole sweep of compile-to-JS languages. Elm is pretty nice in that scenario, and pairs well with my use of Elixir on the backend.

dhbradshaw 10y ago

All these discussions miss the point to me: React can be run natively on Android and iOS. Can Angular? Vue? Elm? It seems like there can't be any real competition when starting a large class of new projects until the answer is "yes." So I'm asking: what are the best real alternatives that work natively on mobile?

_some_guy 10y ago
Check out NativeScript, you can use Angular 2 to build native mobile apps.
- nadermx 10y ago
  I'm still torn, most everyone I have talked too that did a non native app said they would never do it again and would rather do native.
  - dbbk 10y ago
    NativeScript does make native apps. It's in the name.
    - LeoNatan25 10y ago
      Agree that NativeScript is the most "native" of the JS cross platform tools, since it can use actual native concepts, such as controllers, views, gesture recognizers, etc, whereas things like RN throw the "native" word everywhere, but actually implement everything internally in JS. A small example - a tap gesture in RN is actually implemented using `touchesBegan:` API, which routes input to JS over RN bridge, JS performs the tap logic. Doesn't sound terrible, but consider that the RN bridge is async, so the user experiences a floaty behavior, and if that single JS thread is busy with some business logic, you are dead. Same for animations and interactions. Navigation is a joke, with current and other implementations being JS replicas of the real thing, and the native NavigatorIOS, the one to use actual native iOS concepts, being deprecated. NativeScript also has a novel idea how to implement multithreading in JS, which is commendable.

matmo 10y ago

Only some of these are percieved advantages over Angular. Alot of them are advantages over AngularJS, meaning AngularJS 1.x I'm obviously biased, but using Angular (2+) with typescript and ngrx (observable based redux, essentialy) has been really nice to develop with.

jordic 10y ago
Till you try to build a web c omponent or embed an agular2 app in an existent DOM (haha)
- matmo 10y ago
  How are you going to embed an app in another app/DOM without using an iframe, and how is creating that iframe going to be any harder to accomplish depending on the technologies used inside of it? I'm not sure what you mean about components...Angular is component based. Are you referring to native web components?
  - jordic 10y ago
    Take a rich component from your angular UI/lib and export it as a web element. (React/preact/vue/polymer) can! Manage an stream of html comming from a backend CMS. An upgrade their DOM.
    - matmo 10y ago
      I see. Yeah, Angular probably doesn't target environments where it isn't the main/driving DOM/context.
      - jordic 10y ago
        That's one of the problems.. it only covers an slice of the front-end space. And also there is some kind of lock-in.. you can't reuse your components for something else.

sweetheart 10y ago

I find it hard to switch away from React to another similar library/framework simply due to the community that surrounds the "React ecosystem". Having worked on applications using Angular and Vue, I've just had such an easier time solving my problems when using React because there just seem to be more man-hours sunk into developing best practices, which naturally leads to more mature libraries, frameworks, solutions, etc. There are many things that the "React ecosystem" has taught me that I can apply to any future application I build regardless of the stack, but many of my problems were solved in little time because the SO answer to my questions also used React, or the answer came in the form of a React component I could plug in and not worry about. Maybe when Vue's community is as thoroughly developed I'll try that out again. Right now it's hard to find a reason to switch.

josinalvo 10y ago

Just a bug report: In the end of the article Mr. Rwieruch offers a free ebook to those that join his mailing list, unfortunately that does not happen. You are instead sent (after confirming your email) to a site that lists the 'minimum price' of the book as free, gives you a price slider that cannot go bellow 14.99 (and the "additional information icon" when hovered, shows a minimum price of 14.99, contradicting the page's own previous claim) A resolution that allows other users to aquire the free ebook is preferred, but removing the offer of a free ebook would also solve the problem.

rwieruch 10y ago
Hi josinalvo, can you try the page again? As a student, the eBook should be pay what you want. You are the first person who reports the issue unfortunately. Sorry for the inconveniences.
- josinalvo 10y ago
  No problem. Thanks for the prompt response. I had tried as a student before. Just to make sure, I tried again. Slider wont come to less than 14.99. See screenshot: http://5cm.ru/view/i7/AwQ7.png http://5cm.ru/view/i7/AwQ7.png Note that it says free on the page, and minimum=14.99 on the dialog. Also note that student is selected

Garbage 10y ago

My experience with Angular has been very different. I never felt pain working with Angular. Most of the issues I saw, boiled down to bad code. And I think those issues would still be there irrespective of framework used. I also don't get why two way binding is difficult to reason about. Can somebody please give me an example?

jordic 10y ago
Because your state is spread everywhere... I used a lot angularjs before, and it's not bad, but I must admit that the jsx abstraction is so powerful.

wmccullough 10y ago

In other news: Why I moved from table salt to sea salt.

grzm 10y ago
If you feel the topic is inappropriate for HN, flag and move on. Snarky, dismissive comments like this don't add constructively to any discussion.
- solidr53 10y ago
  It's pretty funny tho, I thought immediately of Top Gear

gvb 10y ago

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 <program language dejour> "template" languages (e.g. PHP, Python, ERB, etc.) mixed in with HTML, which also tends to end badly (logic buried in HTML that is hard to find and hard to reason about). How does React solve the "everything mixed into HTML" problem? Are we going down the same path that ended badly last time?

zinckiwi 10y ago
It switches the axis of concern from separating out the different classes of code (HTML, JS, CSS) to separating out the functional goals of your code (Component A does this specific thing, Component B does that specific thing). Realistically, the triad of front end technologies are tightly coupled, regardless of whether they're in the same file. If you can keep your components nicely bounded, then it's far easier to have them be self-contained.
jordic 10y ago
Take the CSS for an small button and add all the variations you need. And after some time someone not so skilled like you arrives and adds a padding to the first button. That on scale it's not easy solvable. And that's the reason why we are looking for other approaches to isolate/share the main functionality.
ariabuckles 10y ago
This sounded scary to me at first, but in practice I've found it to be the opposite. Separating css, html, and js makes sense when you're writing a document, and the content is the html and the css is strictly formatting. It makes less sense when you're writing an app, and the styling of the html is an integral part of what is being created. The javascript works the same way; it's often integral to what's being rendered, not just patchwork adding small amounts of functionality to an existing document. But probably most importantly is that react gives you a different way of separating concerns: it's very easy to put different chunks of the UI into different components/files, so your app is divided by functionality, instead of divided by technology. Keeping the html (and sometimes css) with the js that uses it helps increase the cohesion of small units in your UI that intimately work with each other, while separating those from other js/html/css for other units.

trumbitta2 10y ago

How many of you developers who use React and say that JSX is the second coming of Jesus, are also able to produce a semantically coherent HTML document with JSX? It seems to me that React + JSX are perfect for "divitists" and devs who use a h3 because its font-size has the desired value. I'm not being sarcastic, I genuinely can't understand why a good web developer who cares about the meaning of a HTML document should like JSX.

tomelders 10y ago
Well there's nothing stopping you using the right element for the job. But I would argue that the semantics of HTML, whilst useful in a publication paradigm, don't translate as easily to a web application, which is where React shines. I'd also argue that React is not a good fit for something like a blog, or a news site.
- lllr_finger 10y ago
  This is a great point, and a sword I fell on at my previous employer. React is great for stateful web apps - a blog or a news site have some state, but aren't really that state heavy. Especially when you have a news site getting millions of views, you simply can't afford 1 second on page load to download, parse, and eval React and your data model for little gain. I've seen devs that are so infatuated with React and "isomorphism" that they will use it as a hammer for every screw they come across.
lllr_finger 10y ago
I wouldn't argue that it's the second coming of Jesus, but it's been pleasant to work in. React creates HTML from JavaScript, and JSX is a convenient, intuitive, and familiar way to express your code. I've found that React generates trustworthy HTML, letting me focus on business logic and the interesting parts of development. I've never come across a scenario where React threatened the coherency of my code (other than the data attributes that are now optional, thankfully).
BigJono 10y ago
I must be completely missing your point. React supports the vast majority of html elements. There's nothing I can think of about React that would encourage someone to misuse html, you're using the exact same tags you'd be using to create a vanilla site. The only difference is that you're declaratively defining how they change based on state. A good html developer will still use best practices when using React, a bad one won't. What's the difference?

pinnbert 10y ago

I'm sure many people moved from Angular to React and didn't feel the need to be social about it.

vinhboy 10y ago

Biggest reason: A lot more react jobs than angular jobs.

keyle 10y ago
Really? Where? Here in Australia it's all AngularJS (they're all jobs converting 1.x to 2.0) and sadness :(

rch 10y ago

I'm glad this conversation continues to evolve, particularly now that Angular(2?) has stabilized. Practically speaking though, I'm evaluating high-level frameworks like Blueprint, Clarity, and Element, vs. the prospect of becoming a bespoke framework provider myself (probably not). If I'm starting off with a respectable set of components, then I can adapt to the lower level libraries as necessary.

acemarke 10y ago
I'm pretty happy with Semantic-UI-React myself ( http://react.semantic-ui.com/ http://react.semantic-ui.com/ ). Blueprint does look pretty well designed, too.

jondubois 10y ago

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 which contain other components and both provide clean encapsulation. One of the reasons why I have a slight preference for PolymerJS is that it's much simpler and works with existing HTML concepts (they didn't need to invent a new debugging panel, a new DOM model, a new approach to CSS styling or an advanced state management architecture like Redux to make it work) - Instead, they leveraged existing web technologies. For example, Polymer provides really nice CSS style encapsulation. In PolymerJS, the <style> tag only affects the component in which it's declared (potentially including sub-components but not parent components). It makes CSS really easy to use/maintain without actually reinventing it. 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. You don't need any special module or library or special styling logic; just a <style> tag declared at the appropriate level in your component tree/hierarchy is all you need. That said, the React community is massive and because of this, there are tons of modules and tools around it so it's hard to beat now - It seems that pretty much every problem that React has introduced has since been fixed.

acemarke 10y ago
On the flip side, React's composability and generic component rendering concept allows it to be reused across many non-HTML platforms, including React Native, ReactVR, and more (per this list of React renderers: http://iamdustan.com/react-renderers/ http://iamdustan.com/react-renderers/ ). Also, fwiw, Facebook didn't invent Redux, Dan Abramov and Andrew Clark did _before_ they joined the React team :)
- jondubois 10y ago
  There is nothing inherent to React which makes it easier to render on native platforms. This could easily be achieved with Polymer too - It's just that the Polymer community is much smaller so they're behind in that respect.

Shooogur 10y ago

Yea but the real question is....have you used aurelia?

LocalPCGuy 10y ago

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.

iso-8859-1 10y ago
Which one do you suggest would just be the parts?
- xchaotic 10y ago
  React is built out of components

andrew_wc_brown 10y ago

Mithril is the best.

tmpxxx 10y ago

I think some people just don't get React. The beautiful thing about it is that it's really simple. Yes you create components but it's not just about components. The idea that you can treat your app ass a function and just feed it one global state is what makes it so powerfull imo. That being said there are a lot of paradoxes with react. For example it was created with functional ideas in mind and the functional comunity loves it, but at the same time i have the impression that the facebook deeloppers building it just didn't got it for a long time, and its still sinking in. Just looking at how there are classes for everything and all. It looked mor OO at the begining. And the whole flux, one would think they dont't understand the power of simplicity completly. Then there is the problem of finding the correct patterns to work with it. A lot of times you have OO people that start writing js software and when you look at the code they produce you feel like crying. Then they blame react because they just don't know how to think different.

0x54MUR41 10y ago

I have experience building a mobile app using Ionic framework. Ionic uses Angular for its view library. In my opinion, one thing that I dislike about Angular is documentation. I think Angular has lack of documentation. It has short explanation and no examples/use case for that function. I don't know if the documentation has changed since then because I built that app in 2015. Now, when reading Hacker News, a lot of people post about React. I have never learnt before. Maybe, I am late to the party. I must dig posts about React to know its use cases.

rstormsf 10y ago

now you need to move from react to vue.js