
Why I moved from Angular to React - rwieruch
https://www.robinwieruch.de/reasons-why-i-moved-from-angular-to-react/
======
hakanderyal
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
You should give Elm a look, then.

~~~
pka
And after that, PureScript :)

------
jondubois
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
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
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.

------
gvb
_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?

~~~
shados
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.

~~~
gambler
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 not declarative. There is no way to examine them without
executing code. This is an elephant in the room most fronted developers
willfully ignore right now.

~~~
andybak
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"

------
sweetheart
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.

------
aviraldg
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.)

------
josinalvo
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
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
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

------
matmo
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
Till you try to build a web c omponent or embed an agular2 app in an existent
DOM (haha)

~~~
matmo
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
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
I see. Yeah, Angular probably doesn't target environments where it isn't the
main/driving DOM/context.

~~~
jordic
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.

------
Garbage
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
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.

------
dhbradshaw
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
Check out NativeScript, you can use Angular 2 to build native mobile apps.

~~~
nadermx
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
NativeScript does make native apps. It's in the name.

~~~
LeoNatan25
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.

------
trumbitta2
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
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
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.

------
tmpxxx
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.

------
LocalPCGuy
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
Which one do you suggest would just be the parts?

~~~
xchaotic
React is built out of components

------
rch
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
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.

------
0x54MUR41
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.

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

~~~
keyle
Really? Where?

Here in Australia it's all AngularJS (they're all jobs converting 1.x to 2.0)
and sadness :(

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

------
rstormsf
now you need to move from react to vue.js

------
andrew_wc_brown
Mithril is the best.

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

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

~~~
grzm
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
It's pretty funny tho, I thought immediately of Top Gear

